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This  report  is  concerned  with  the  problem  of  achieving  flexibility 

and  efficiency  (performance,  expertise) 
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electronic  circuit  design.  The  proposed  solution  is  to  provide  a rlcdurt  inn- 
driven  problem  solver  with  built-in  control-structure  concepts.  This  prrihlnm 
solver  and  its  knowledge  base  in  the  application  areas  of  design  anri 
electronics  are  described.  The  program  embodying  it  is  being  used  to  nxplore 
the  solution  of  some  modest  problems  in  circuit  design.  It  is  concluded  that 
shallow  reasoning  about  problem-solver  plans  is  necessary  for  flexibility,  and 
can  be  implemented  with  reasonable  efficiency. 
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I Introduction 
I . A The  Prob I em 

This  thesis  reports  on  the  exploration  of  a classic  AI  controversy 
regarding  the  representation  and  use  of  knowledge:  the  trade-off  between 
flexibility  (or  modularity  or  additivity)  on  the  one  hand,  and  efficiency  (or 
expertise  or  performance)  on  the  other.  It  focuses  on  the  knowledge  required 
for  designing  elementary  electronic  circuits.  The  conclusions  I have  reached 
are  that  this  kind  of  flexibility  requires  all  important  operations  to  be 
mediated  by  explicit  rules  driven  by  changes  to  an  associative  data  base;  and 
that  the  inevitable  inefficiency  of  this  organization  can  be  controlled.  The 
proposed  approach  has  been  tested  by  implementation  of  an  extensible  design 
program  called  DESI . 

The  theory  of  design  that  I have  implemented  is  based  on  the  idea  of 
"functional  reasoning."  (Freeman  and  Newell,  1971)  A problem  is  stated  as  a 
property  which  an  electronic  circuit  is  to  have.  The  system  searches  its 
memory  for  circuits  whose  known  functions  fit  the  requirement.  In  the 
attempt,  it  constrains  the  connectivity  and  component  values  of  the  circuit 
until  enough  constraints  have  accumulated  to  find  values  which  satisfy  the 
original  property.  This  simple  theory  must  be  complicated  in  various  ways;  A 
requirement  may  not  be  expressed  in  a form  which  triggers  suggestions  of 
familiar  circuits;  it  may  be  necessary  to  transform  the  requirement  until  it 
does.  More  than  one  device  type  may  bo  brought  to  mind  in  a situation;  there 
must  be  criteria  for  deciding  among  them,  or  ways  of  synthesizing  new  circuits 
that  perform  the  functions  of  all  the  ones  retrieved.  A suggested  circuit  may 
not  work  out;  the  theory  must  specify  how  plans  are  changed. 

I require  that  the  embodiment  of  this  theory  be  "additive";  that  is,  to 
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the  extent  possible  that  neu  knowledge  be  expressed  bg  new  formulas  rather 
than  by  changes  to  old.  This  is  partly  because  of  the  ease  with  which  such  a 
system  can  absorb  new  information;  and  partly  because  a creative  designer 
requires  the  ability  to  see  the  individual  parts  of  its  various,  often 
conflicting,  plans  and  goals.  For  this  reason,  the  theory  is  embodied  as  a 
"rule-based"  system. 

By  a "rule-based"  system  I mean  a system  uhich  makes  progress  by  pattern- 
driven  operations  on  a data  base.  There  are  several  paradigms  for  such 
systems;  the  classical  ones  are  predicate-calculus  theorem  provers  (Nevins, 
197Aa) , production  systems  (Newell,  1973a),  and  AI  languages  with  pattern- 
directed  procedure  invocation.  (Hewitt,  1972,  Bobrow  and  Raphael,  197A)  In 
what  follows,  I will  attempt  a synthesis  of  good  features  of  all  of  these. 

The  result  may  be  described  as  a system  in  which  plans  are  assembled  piece  by 
piece.  The  rules  used  resemble  predicate-calculus  implications.  They  differ 
in  these  ways:  they  may  be  used  to  infer  what  tasks  are  required  or  what 

solutions  are  possible;  they  are  less  constrained  in  the  kind  of  inference 
rule  and  " se  I f -r  e f erent  i a I " deductions  allowed;  they  specify  how  they  are  to 
be  used;  and  they  come  in  larger,  better  organized  chunks  than  is  traditional 
in  predicate-calculus  applications. 

Before  elaborating  further  on  these  requirements,  let  me  bring  these 
problems  to  life  with  two  examples  from  elementary  electronic  design, 
illustrating  as  i go  how  DESi  deals  with  them.  The  first  example  shows  how 
choices  must  often  be  based  on  knowledge  of  current  plans.  The  second  example 
illustrates  some  of  the  other  complexities  I mentioned.  (These  informal 
scenarios  are  meant  to  give  you  a picture  of  the  design  problems  DESI  is  meant 
to  handle,  not  the  structure  of  the  program  or  its  actual  behavior.  1 will  go 
over  these  problems  again,  once  in  this  chapter  to  illustrate  the 
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representation  and  use  of  knouledge  by  the  system,  and  again  in  Chapter  V to 
shou  the  performance  of  the  actual  implementation.) 

Redescribing  Problems  and  Choosing  Solutions 

Imagine  that  DESI  ie  given  the  problem,  "Design  an  amplifier  uith  an  input 
resistance  of  30  kohm  and  a voltage  gain  of  B."  For  nou,  let  us  assume  this 
problem  ui  I I be  broken  into  the  three  subrequirements,  "amplifier,"  "input 
resistance  • 30  kohm,"  and  "v-gain  « B."  (This  must  be  done  uith  care,  since 
these  three  characteristics  are  of  rather  different  kinds.)  This  is  only  part 
of  the  problem,  for  these  fragments  of  the  original  problem  are  too  precise  to 
be  suggestive;  DESI  must  further  alter  the  description  so  that  these  numbers 
become  "range  descriptions"  like,  "high  input  impedance"  and  "moderate  voltage 
gain."  (See  Fig.  I.l.) 

"amplifier  uith  input  resistance  » 30  kohm  and 
VO  I tags  gain  - B" 

\ / 

I I becomes 

I I 

V 

"amplifier"  < thing  to  make 

"input  resistance  30K"  < high  input  resistance 

"voltage  gain  B"  < moderate  v-gain 

Figure  I.l  Redescribing  a Design  Problem 
Once  the  problem  has  been  described  in  this  form,  its  fragments  trigger 
suggestions  of  possible  solutions.  For  example,  in  the  context  of  making  an 
amplifier,  "high  input  impedance"  should  suggest  "common-collector  amplifier," 
and  "moderate  voltage  gain"  should  suggest  "common-eiiii  t ter  amplifier."  (Fig. 


1.2.) 


I Introduction 


10 


high  input  resistance 

+ V< 


.POWER 


cc 


high  voltage  gain 

+ Vcc" 


COMMON  COLLECTOR  COMMON  EMITTER 


Figure  1.2  Two  Circuits  Suggested  by  Parts  of  the  Problem 
If  just  one  of  these  had  been  suggested,  the  problem  would  be  easy;  OESI 
could  select  a standard  schema  for  the  type  that  came  to  mir.d  and  make  sure 
j the  given  numerical  constraints  could  indeed  be  satisfied.  Uhat  must  it  do 

, when  two  or  more  options  occur?  In  some  cases,  all  but  one  may  be  excluded  on 

I 

( the  basis  of  further  considerations  beyond  the  simple  problem  features  that 

! 

\ suggested  the  competing  options;  often,  however,  what  is  required  is  a 

I synthesis  which  combines  two  suggestions  to  provide  the  functions  of  both.  In 

* this  case,  DESI  must  possess  information  to  the  effect  that  an  option 

« 

suggested  because  of  what  it  does  for  an  amplifier's  input  resistance  may  be 
"cascaded"  with  another  option. 

So  far,  I have  drawn  these  circuits  as  if  they  always  contained  the  parts 
shown.  However,  the  notions  of  "common-collector"  and  "common-emitter" 
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amplifier  each  corresponds  to  a range  from  general  to  specialized  circuits. 
Uhen  a common-emitter  amplifier  simpllciter  is  desired,  the  circuit  of  Fig. 

1.2  is  selected  almost  uithout  thought.  But  a practiced  designer  knows  that 
the  "abstract  idea"  of  this  circuit  may  be  realized  in  other  ways.  To  cascade 
the  two  circuits  of  Fig.  1.2,  DESI  would  not  just  "draw"  the  same  two  pictures 
and  cram  them  together  in  some  way.  Instead,  it  chooses  more  general  diagrams 
of  these  circuits,  and  reconsiders  how  they  are  to  be  biased  and  coupled. 

This  will  involve  further  choices.  The  result  is  the  circuit  of  Fig.  1.3. 


Figure  1.3  A Cascade  of  the  Two  Partial  Circuits 
Finally,  the  numerical  constraints  set  aside  in  favor  of  more  revealing 
descriptors  are  taken  up  again  to  give  the  component  values  shown  in  the 
figure. 
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Transforming  Problem  and  Solution 

In  this  second  example,  I wish  to  show  hou  much  more  complicated  the 

phases  of  design  can  get.  Imagine  that  the  problem  given  is 

Design  a network  which  converts  a IkHz  square  wave  of  amplitude  IV  into  a 
sine  wave  with  the  same  frequencg  and  amplitude. 


1kHz 

injii 


1kHz 


Figure  1.4  Signal  Conversion  Problem 

Even  if  you  know  nothing  about  electronics,  it  mag  be  worth  thinking  about 
this  problem  for  a minute  before  going  on.  (You  don’t  have  to,  but  the 
problem  can  be  amusing,  and  illustrates  an  interesting  and  common  phenomenon 
of  problem  solving.) 

* « * 


1 


♦ 
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If  you  know  Bonte  elementary  mathematica,  it  probably  occurred  to  you  to 
take  the  Fourier  series  of  each  of  these  signals.  In  this  “ freQuency  domain, 
the  problem  becomes: 

Desian  a netuork  which  converts  a signal  with  spectrum 


1 . 

height  :4/n«^ 
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1 t 1 ^ i ♦ 1 ♦ 1 
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1 2 3 4 5 6 7 8 9 10  11  12  13 

Figure  1.5  Spectrum  of  Square  Uave 

into  a signal  with  spectrum 

- 

i > 1 

I I t I I I t t I I I t 

1 2 3 4 5 6 7 8 9 10  11  12  13 

Figure  I.G  Spectrum  of  Sine  Uave 
such  that  the  amplitude  of  the  spike  at  IkHz  is  IV. 

If  you  know  some  electronics,  it  might  then  have  occurred  to  you  to  try  a 
lom-pass  niter  circuit  like 
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(if  not  loaded) 


When  used  for  low- 
pass  filtering  above 
cutoff  frequency  f. 


Figure  1.7  RC  Fi I ter 

as  your  ansuer,  and  then  try  as  before  to  finish  the  problem  off  by  assigning 
values  to  the  primitive  components  (here,  the  capacitor  and  resistor)  uhich 
satisfy  the  constraints  we  have  discovered. 

The  interesting  constraints  on  this  circuit  may  be  stated  as  follows, 

"Make  the  amplitude  of  the  output  spike  at  3 kHz  less  than  10X  of  the 
amplitude  of  the  output  spike  at  1 kHz." 

"Make  RC  bo  the  reciprocal  of  the  frequency  1 kHz  (in  rad/sec)." 

"The  ratio  of  the  amplitudes  of  the  outputs  at  two  frequencies  depends  on 
the  amplitudes  of  the  inputs  and  the  selectivity  of  a device." 

"The  selectivity  of  an  RC  filter  is  ..." 

OESI  can  derive  these  constraints  from  the  statement  of  the  problem  (starting 
with  a lot  of  knowledge  about  RC  filters  and  frequency-domain  operations). 

Unfortunately,  these  constraints  cannot  be  solved  simultaneously.  The 
circuit  given  will  make  a square  wave  look  "rounder,"  but  the  approvimat  ion  to 
a sine  wave  will  not  be  good  enough.  The  constraint  that  deserves  the  blame 
in  this  case  is  that  on  the  selectivity  of  an  RC  filter.  How  can  this  be 
Improved?  One  way  is  by  "adding  a pole"  to  its  system  function  with  this 


clrcui t j 


I I ntrotluc  t i on 


15 


A 


New 

OUTPORT 


New  system  function  r old  x L . 

1 + R'C's 


(Remember  to  implement  A.) 


Figure  1.8  A Circuit  for  Adding  a Pole 

This  Makes  OESI's  vieu  of  the  solution  much  more  promising.  (I  won’t  pursue 
this  eMample  ang  further,  because  the  current  implementation  lacks  the 
coMpetence  to  go  any  further.) 


Let  me  list  the  various  types  of  information  that  I appealed  to  in  mg 
brief  overview  of  how  such  problems  may  be  solved.  First,  DESI  needs 
knowledge  about  transforming  the  problem  into  a tractable  form;  this  ranges 
froM  a relatively  simple  sorting  out  of  multiple  requirements,  to  a more 
difficult  transformation  from  a time-domain  to  a frequency-domain  description 
of  a probleM.  Second,  and  quite  inportant,  there  had  to  be  a basis  for 
choosing  among  more  than  one  approach.  Third,  several  constraints  had  to  be 
satisfied  in  a consistent  wag.  This  required  knowledge  of  the  physics  of 
electronic  circuits.  Fourth,  we  had  to  be  able  to  change  plans  when  our  first 
try  failed. 

To  make  all  these  kinds  of  information  usable,  DESI  has  to  be  able  to 
reaeon  about  ite  current  plans  and  goals.  Transforming  a problem  mag  be  seen 
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as  redescribing  the  topmost  goal.  Choice  of  a solution  to  one  problem  often 
depends  on  the  other  problems  under  consideration.  The  calculation  of  a 
design  quantity  to  satisfy  one  constraint  is  pointless  unless  all  the  other 
constraints  on  that  quantity  are  taken  into  account.  And,  of  course,  one 
cannot  change  plans  without  knowing  what  they  are.  An  organization  which 
makes  using  such  knowledge  practical  has  been  the  goal  of  this  research. 

I.B  A Rule-Based  Problem  Solver 

Here  is  my  thesis;  problems  are  solved  by  reducing  them  to  subproblems. 

Some  of  these  subproblems  result  in  action,  others  in  constraints  on  action. 

As  the  solution  progresses,  the  way  in  which  new  suhproblems  are  approached 
depends  more  and  more  on  the  state  of  other  subproblem  solutions,  that  is,  on 
the  requirements  derived  from  the  physics  of  the  evolving  solution  and  on  the 
goal  structures  that  have  already  been  elaborated.  It  is  impossible  to  know, 
as  new  facts  are  discovered,  what  subsequent  suhproblems  will  depend  on  them, 
so  all  such  facts  must  be  stored  in  the  same  communal  data  base  and  accessed 
whenever  they  become  relevant  to  a later  problem  reduction. 

This  is  accomplished  by  implementing  DESI  as  a set  of  rules  manipulated  by 
a rule-based  problem  solver  called  NASL.  A rule-based  system  (Shortliffe,  i 

• I 

197G,  Oavis  and  King,  1975)  is  one  in  which  knowledge  is  expressed  as 
conceptually  small  units  called  rules. 

There  are  two  sources  of  inefficiency  in  a system  organized  this  way;  the 
overhead  paid  for  storing  almost  all  knowledge  in  the  same  associative  data 
base,  and  the  nondeterminism  inherent  in  the  possibility  that  more  than  one 
rule  may  apply  to  a problem.  The  first  kind  of  inefficiency  is  the  price  of 
flexibility,  but  it  can  be  limited  by  proper  organization.  One  important 
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principle  ot  organization  is  allou  rules  to  come  in  we  I I -organi zed  chunks.  In 
OESr,  these  "packets"  of  rules  (HcDermott.  1975)  are  used  to  represent  circuit 
diagrams,  signal  descriptions,  partial  plans  for  solving  problems,  and  groups 
of  rules  for  making  choices. 

The  second  source  of  inefficiency,  nondotermini sm,  can  be  controlled  by 
confining  it  to  the  information  retrieval  module.  Above  this  lowest  level, 
potential  nondeterminism  is  shut  off  by  applying  "choice  rules"  in  ambiguous 
si  tuations. 

In  this  section  and  the  next,  I will  sketch  the  form  and  content  of  DESI’s 
rules.  This  sketch  will  be  filled  in  in  Chapters  II,  III,  and  IV,  Chapter  V 
gives  the  results  that  have  been  obtained  by  implementing  it. 

In  any  rule-based  system,  each  rule  is  associated  with  a pattern  by  which 
the  system  accesses  it.  The  system  also  maintains  a data  structure,  the 
"active  processing  site,"  that  is  intended  to  describe  important  aspects  of 
the  current  situation.  Rules  are  matched  against  this  structure,  and  rules 
whose  patterns  match  are  applied  in  some  way. 

The  potential  advantages  of  a rule-based  system  are  these:  (1)  the  system 
can  see  what  it  is  doing  because  important  steps  occur  at  standard  times  in  a 
standard  way;  (2)  the  system  can  keep  track  of  its  deductions  and/or  actions 
in  order  to  explain  or  undo  them;  (31  the  system  can  be  augmented  simply  by 
adding  new  rules. 

Realizing  these  potential  advantages  has  not  been  easy.  There  are  three 
classic  types  of  rule-based  systems: 

(1)  Predicate-Calculus  Theorem  Provers  — Here  the  rules  are  axioms  and 
the  currently  active  processing  site  is  that  rule  which  is  being  treated  as  a 
goal.  Applying  a rule  generates  new  rules  or  answers  to  the  problem  at  hand. 
(Robinson,  1965,  Nilsson,  1971,  Nevins,  197Aa,  R.  floors,  1975) 


(2)  Production  Systems  — Here  the  rules  are  condition-action  pairs,  or 
"productions,"  and  the  current  alts  is  a small  list  called  the  "Short-Term 
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Memory,"  or  STM.  Applying  a rule  consists  of  performing  manipulations  on  the 
STM  or  doing  simple  input/output  operations.  (Rychener,  197G.  Neuell,  1971a) 

(3)  Artificial  Intelligence  Programming  Languages  --  These  languages  may 
be  said  to  be  rule  based  if  pattern-directed  procedure  invocation  is  taken  as 
rule  application  and  if  such  procedures  are  taken  as  rules.  The  processing 
site  is  a flexible  record-oriented  data  base,  in  particular,  the  recorrls 
currently  being  added,  deleted,  or  retrieved.  These  languages  include  PLANNER 
(Hewitt,  1972)  and  its  descendants  QAA  (Rulifson  et.  al . , 1972)  and  Conniver 
(Sussman  and  McDermott,  1972). 

(More  specific  examples  will  be  mentioned  for  comparison  with  NASL  later.) 

All  of  these  systems  have  suffered  from  problems  which  have  kept  them  from 
realizing  their  potential.  The  predicate-calculus  systems  are  the  least 
deterministic  of  the  group.  The  control  of  application  of  pr ed i ca te-ca I cu I us 
rules  has  not  itself  been  rule-directed  or  directed  by  much  knowledge  of  any 
kind.  However,  one  of  their  strong  points  is  that  the  proofs  they  generate 
play  a natural  role  in  keeping  track  of  their  actions  or  justifying  them  to  a 
human  user. 

Production  systems  have  very  low-level  rules.  The  system  provides  simple 
symbo  I -man  i pu  I at  i on  ability,  but  each  programmer  must  provide  his  own  control 
concepts,  starting  at  the  level  of  the  subroutine  call.  This  tends  to  defeat 
real  extensibility,  since  two  sets  of  rules  probably  have  different  calling 
conventions.  (Production  systems  have  been  evolving  toward  greater  richness.) 

AI  languages  provide  more  direction  and  control  over  problem  solving,  but 
at  the  cost  of  making  "rulishness"  only  a token  aspect  of  procedures.  The 
small  patterned  interface  between  a program  and  its  callers  is  usually  dwarfed 
by  the  body  of  the  procedure.  Other  procedures  know  that  this  one  is  there, 
but  they  do  not  know  what  it  is  doing, 

A general  problem  of  all  these  systems  is  that  they  are  insensitive  to 
important  aspects  of  their  own  operation.  Production  systems  and  pattern- 
directed  procedures  generally  do  not  m.>pipulate  themselves.  (That  is,  systems 
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built  on  them  do  not  encourage  or  simplify  this  any  more  than  the  LISP 
Interpreter  in  uhich  they  are  generally  embedded.) 

To  remedy  these  defects,  I have  implemented  the  NASL  rule-based  system  to 
depend  heavily  on  explicit  representation  of  control.  NASL’s  active 
processing  site  Is  a PLANNER-type  data  base  of  rules,  but  more  is  stored  there 
than  In  the  typical  Al-language  system.  Besides  a model  of  the  current 
problem  situation,  the  data  base  includes  a representation  of  the  "current 
plan,"  Rules  are  used,  not  to  trigger  actions  directly,  but  to  add  tasks  to 
this  representation.  Uhen  the  rules  are  used  in  a f oruard-deduc  t i ve  nay,  they 
resemble  productions,  with  an  extra  layer  of  "carefulness"  between  application 
of  the  rule  and  actual  execution  of  the  task,  (Sussman,  1975)  Uhen  the  rules 
are  used  in  a backward-deductive  way,  when  the  interpreter  is  attempting  to 
find  a way  of  carrying  out  a task,  they  augment  the  plan  much  the  way  a 
PLANNER- 1 ike  language  invokes  procedures. 

The  difference  between  a plan  and  a procedure  is  that  a plan  may  represent 
action  at  a more  abstract  level.  In  particular,  the  order  of  steps  within  and 
between  subplans  is  itself  rule-governed.  Furthermore,  not  all  tasks 
correspond  to  subroutine  calls  to  bring  something  about  or  calculate 
something.  Some  tasks  are  intended  to  represent  "parasitic"  actions  which 
influence  the  execution  of  other  tasks,  or  uhich  require  occasional  commitment 
of  resources.  Examples  from  circuit  design  are  the  actions,  "Constrain  RC  to 
be  l/2nr,"  "Make  sure  every  requirement  in  the  given  design  problem  is 
accounted  for,"  and  "Take  note  of  the  high-gain  requirement  in  making  this 
amp  I i f i er . " 

These  secondary  tasks,  or  "policies,'’  are  particularly  useful  in  choice 
situations,  in  which  the  problem  solver  tries  to  decide  among  more  than  one 
course  of  action.  The  existence  of  a policy  often  amounts  to  the  existence  of 
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certain  rules  for  suggesting  options  or  deciding  among  them. 

Another  important  difference  betueen  Al- language  procedures  and  NASL  plans 
is  that  plans  are  completeig  deterministic.  All  search  is  done  in  the  rule- 
appliers  that  try  to  retrieve,  construct  or  choose  among  plans.  If  the 
resulting  plan  does  not  work,  a "mistake  correction"  plan  must  be  sought  uhich 
is  appropriate  to  the  kind  of  mistake  that  occurred. 

Inability  to  retrieve  a solution  plan  via  the  simple  deductive  retrieval 
mechanism  does  not  cause  any  kind  of  "failure."  Instead,  the  system  attempts 
to  transform,  or  "rephrase,"  the  problem  until  it  is  in  a more  familiar  form. 
This  requires  that  the  rules  and  records  of  the  system  be  manipulable  by 
rephrasing  tasks. 

To  explain  its  actions  and  correct  its  mistakes,  the  system  must  keep 
records  of  uhy  it  did  yhat  it  did.  These  are  of  two  kinds:  stored  chains  of 
rule  applications,  and  relations  betueen  tasks.  The  user  may  ask  for  an 
explanation  of  a task  in  terms  of  the  tasks  it  was  designed  to  accomplish. 

The  system  may  edit  these  netuorks  of  relations  uhen  it  runs  into  trouble. 

I mentioned  at  the  beginning  of  this  section  that  rule-based  systems  are 
potentially  "extensible,"  that  is,  able  to  accept  neu  information  additively, 
uithout  major  reorganization.  Ue  can  distinguish  short-  from  long-range 
extensibility.  Over  the  long  range,  putting  neu  information  in  is  part  of  a 
eimple  but  important  kind  of  learning — "taking  advice."  It  is  not  the  only 
part,  because  reorganizing  descriptive  structures  and  debugging  or 
disambiguating  uhat  one  is  told  are  also  crucial. 

Therefore,  it  is  easier  to  see  the  importance  of  extensibility  over  the 
short  range.  It  is  common  in  AI  research  these  days  to  assume  that  knowledge 
is  represented  in  large,  ue I I -organi zed  chunks  (usually  called  "frames"). 
(Minsky,  197A)  Assuming  this  to  be  true,  ue  still  have  the  problem  of 
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interactions  of  tuo  simultaneously  active  chunks.  This  is  just  the 
extensibility  problem  in  the  small,  since  each  chunk  appears  to  the  other  to 
contain  neu  Information  that  may  be  relevant.  Unless  all  frame  interactions 
have  been  foreseen  in  advance  (uhich  is  normal  in  most  computer  science,  but 
not  in  Al),  the  information  in  each  chunk  must  be  expressed  in  terms  the  other 
can  understand.  (This  is  why  programs  appear  to  me  to  be  such  a poor  frame 
representation,  since  a program  is  just  a large  chunk  of  lines  of  code,  none 
of  which  means  anything  outside  of  its  particular  context.)  At  the  very 
least,  a system  must  notice  potentially  relevant  interactions  and  ask  for 
further  information  when  it  does. 

In  NASL,  each  rule  resembles  a Skolemized  formula  of  predicate  calculus. 
(Robinson,  19G5)  (In  fact,  few  substantive  restrictions  on  predicate  calculus 
have  been  preserved  in  this  notation.)  The  rules  are  manipi/lated  by  a 
PLANNER-1  ike  theorem  prover.  (Cf.  R.  floore,  1975)  However,  the  rules  can  come 
in  large  chunks  called  "packets."  (hcOermott,  1975)  Packets  can  include  other 
packets  (since  they  are  logically  just  large  conjunctions  of  formulas).  One 
use  of  this  is  the  implementation  of  hierarchies  like  those  of  "semantic 
network"  systems.  (E.g.,  Bobrow  and  Uinograd,  197GI  Circuit  diagrams,  among 
other  things,  are  stored  as  packets. 

There  are  several  "framish"  concepts  used  in  implementing  NASL.  For 
example,  the  active  tasks  of  the  current  plan  might  correspond  to  the 
"important  questions"  terminals  of  a tiinskian  frame,  (flinsky,  1974)  However,  I 
have  felt  free  to  diverge  from  the  orthodox  conventions  of  frame  theory,  and 
one  must  not  assume  that  "plans"  or  "packets"  correspond  directly  to  frames. 
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I.C  Supplying  Rules  for  Design 

To  apply  NASL  to  a problem  domain,  knowledge  about  that  domain  must  be 
supplied  in  the  form  of  rules.  The  major  rule  sets  I have  developed  are  for 
design  in  general  and  electronics  in  particular.  Uhen  they  are  added  to  NASL, 
the  system  has  the  structure  shown  in  Fig.  1.9. 
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Design  Electronics  Current  Data 

Knowledge  Knowledge  Pool 


/\  / \ 


EVAL 
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Figure  i.3  Structure  of  DESI 

The  program,  loosely  known  as  DESI,  has  the  following  hierarchical 
organization  (from  the  bottom  up): 

STP  --  A PLANNER- 1 ike  theorem  prover 

EVAL,  CHOOSE,  REPHRASE  --  non-standard  inference  mechanisms 

NASL  --  The  interpreter  for  plans 

DESI  (proper)  --  A set  of  rules  for  designing  hierarchical  systems 

ZORCH  — Rules  embodying  electronics  knowledge 

The  rules  themselves  are  highly  structured.  Some  of  them  specify  physical 
relations  among  things  like  nodes  and  signals.  Higher-level  rules  are  used  to 
influence  problem  choice  and  transformation.  Almost  all  of  them  have  some 
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procedural  component,  in  that  they  refer  to  the  current  task  network.  For 
example,  even  the  simplest  statement  of  Ohm’s  law,  that  the  current  ttirough  a 
resistor  equals  its  voltage  over  its  resistance,  is  stated  as  a constraint  on 
the  values  of  these  physical  quantities. 

Most  of  the  "raw  information"  in  the  system  is  stored  in  packets  defining 
known  circuits,  such  as  common-emitter  amplifiers,  voltage  dividers,  etc. 

Uhen  a circuit  of  a given  type  is  created,  its  packet  will  be  instantiated. 
Each  such  packet  contains  information  of  these  kinds: 

(1)  Component  definitions  like 

tCOnPONENTS  ?»<fVOLTAGE -DIVIDER 

<(R1  ?/»/fV0LTAGE -DIVIDER)  (R2  ?/lf<fVOLTAGE-DI  VIOER)  >1 

(NASL  formulas  are  always  enclosed  in  (brackets).  See  Appendix  1 for  rietaile 
of  this  and  subsequent  NASL  notation.  The  prefix  "?*  indicates  a predicafe- 
calculus  variable;  in  a packet,  refers  to  an  object  that  will  be  bound 

later  to  a particular  instance  of  the  concept  the  packet  describes. 

(McDermott,  1975).  Angle  brackets  enclose  tuples.) 

(2)  Connection  specifications  like 

(NODES  ?«)lfVOLTAGE -DIVIDER 

<(T0PN00E  ?ltr<fVOLTAGE-DIV|DER) 

(MIDNOOE  ?»<fV0LTAGE -DIVIDER) 

(BOTNOOE  ?(f<fVOLTAGE-D|VIDER)>) 

(NODE -TERM INALS  miDNOOE  ?mOLTAGE-DI VIDER) 

<«f2  (R1  ?/»(fV0LTAGE -DIVIDER)) 

OKI  (R2  ?*f<fVDLTAGE-DIV|DER))>) 

(3)  Constraints  and  other  "frozen  tasks"  which  will  be  awakened  when  an 
instance  of  the  packet  is  created.  These  are  used  to  associate  with  a device 
a description  of  its  purposes  and  further  requirements.  The  commentary 
appearing  around  the  diagrams  in  Fig"*.  1.2,  1.7,  and  1,8  is  represented  as  a 
set  of  such  tasks. 

These  circuits  come  in  hierarchies  of  various  kinds.  The  components  of  3 
circuit  may  themselves  be  circuits.  Circuits  may  be  arranged  in  classes  (such 
as  "amplifier")  which  share  properties.  One  circuit  may  he  derived  from 
another  by  assuming  special  conditions;  for  example,  the  specific  and  general 
common-emitter  circuits  I pointed  out  in  Sect.  I.A  are  of  this  type.  All  of 
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these  hierarchies  may  be  represented  by  the  device  of  allowing  packets  to 
include  other  packets. 

A solution  to  a design  problem  is  represented  as  a structure  of 
instantiated  circuits,  with  primitive-component  values  selectetl.  A top-level 
design  problem  is  of  the  form,  "Find  a circuit  structure  with  proper tg. " 

It  is  the  information  required  to  go  from  property  to  circuit  that  is  of 
most  interest.  This  falls  into  several  classes:  (1)  knowledge  about 

transforming  problems,  (2)  rules  for  making  choices,  (3)  plans  for  altering 
and  improving  circuits,  and  (4)  knowledge  about  physical  fconstraints  on 
quantities.  Each  of  these  categories  is  represented  by  rules  in  DESI  and 
ZORCH.  DESI  is  a small  set  of  design  rules  that  are  intended  to  be 
independent  of  any  one  physical  domain;  it  provides  a vocabulary  and  task 
structure  within  which  ZORCH' s rules  can  operate. 

For  example,  DESI  provides  a standard  framework  for  rephrasing  design 
problems.  The  idea  is  to  transform  an  unfamiliar  design  problem  into  the 
making  of  a familiar  kind  of  circuit  obeying  physical  constraints,  using  more 
suggestive  hints  like  "make  it  linear"  or  "notice  the  high  ga^n."  (Cf.  Sect. 

I. A.)  ZORCH  provides  rules  to  do  this  decomposition  and  then  to  use  the  hints 
and  constraints  to  zero  in  on  a diagram. 

The  DESI  rephrase  plan  contains  tasks  to 

"Explode"  the  given  property  into  "shards." 

Classify  shards  as  to  whether  they  suggest  a familiar  device  type,  a 
constraint,  or  a "design  features"  like  "linearity." 

Gather  the  suggestions  into  a new  task  network. 

In  this  process,  rules  like  this  (from  ZORCHI  become  important: 
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[-/>  A (D-SHARD  ?+P  (X  (_?+V)  (-  (V-GAIN  (/?/?  _?+V))  _?+G))) 

(-/>  G (/>  (DEN  ?+G)  50) 

(D-FEATURE  ?+P  [RANGER  V-GAIN  HIGH]))) 

This  says  that  a voltage  gain  greater  than  50  shoulfl  he  noticed  as  "high.” 

The  symbol  signifies  implication;  the  letter  after  it  identifies  the  uay 

in  which  the  rule  is  to  be  used.  (See  Chapter  II.  The  "A"  means  when  the 

left  side  is  recorded,  record  the  right;  the  "G"  means  call  the  theorem  proven 

to  find  answers  to  the  left  side,  and  record  the  right  side  for  each 

substitution  returned.  The  actual  rules  in  Appendices  2 and  3 are  more 
indirect  and  give  more  information.) 

Once  the  task  network  has  been  transformed,  other  ZORCH  rules  come  into 
play.  These  rules  are  of  these  kinds:  (1)  definitions  of  fundamental  wiring 
operations;  (2)  physical  laws  like  Ohm’s  which  constrain  numerical  quantities; 
(3)  plans  and  pieces  of  plan  for  biasing,  coupling,  and  performing  other 
standard  operations  on  circuits;  (4)  rules  for  choosing  among  suh-typeq  of 
inclusive  circuit  categories  suggested  by  the  rephrase  rules. 

Fundamental  wiring  operations  are  defined  using  the  built-in  relation 
/:nOD-f1ANIP  (for  "model  manipulation").  For  example,  connecting  terminals  to 
form  nodes  may  be  defined  by  this  rule 

(/tnOD-MANIP  7TASK  (CONNECT  ?T1  ?T2)  <> 

<•  (EXISTS  (N)  (AND  (DEV-TYPE  ?N  NODE) 

(NODE-TERMINALS  'i’N  <?T1  ?T2>))  )>). 

This  defines  an  "addlist"  (Fikes  and  Nilsson,  1971)  for  this  action.  (Its 
"deletelist"  is  empty.) 


Physical  laws  are  defined  by  rules  like  this: 
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l-/>  A (DEV-TYPE  ?X  RESISTOR) 

(EXISTS  (T) 

(/:TASIC  ?T  <> 

(X  0 (CONSTRAIN  <’ (V  ?X)  ’(I  ?XI  MR  ?X)> 

(X  (V  I R)  (-  ?V  (*  ?I  ?RH  m 

<>)  II 

which  commits  the  designer  to  the  given  constraint.  CONSTRAIN  is  a kind  of 
policy  action  defined  in  OESI;  again,  DESI  provides  the  vocabulary  for  ZORCH. 

Choice  rules  are  used  for  differential  diagnosis  or  synthesis  of  partial 
solutions.  For  eKample,  in  choosing  an  amplifier,  the  rule 

(-/>  A (/sOPTION  ?C  ’A1  (/: TO-DO  _?+TASK  (MAKE  AMPLIFIER)  <_?+AMP> 

(MAKE  COMMON-COLLECTOR) I ) 

(-/>  A (/:0PTI0N  ?C  ?A2 

(/: TO-DO  _?+TASK  (MAKE  AMPLIFIER)  <_?+AMP> 

(MAKE  COMMON-EMITTER))) 

(/: RULE -TOGETHER  <?A1  ?A2> 

(/:  TO-DO  _?+TASK  (MAKE  AMPLIFIER)  <_?4-AMP> 

(MAKE  (CASCADE  COMMON-COLLECTOR 

COMMON-EMITTER)))))! 

This  rule  says  that  a common-collector  amplifier  and  common-emitter  amplifier 
may  be  cascaded  to  accomplish  the  purposes  of  both.  (The  actual  rule  comes 
closer  to  saying  this.)  The  conclusion  l/sRULE-TOGETHER. . . ) is  used  by  the 
choice  protocol  of  Fig.  1.9.  It  is  used  to  specify  composition  of  separately 
unsatisfactory  choices;  /:RULE-IN  and  /:RULE-C)UT  are  used  to  narrow  the  list 
of  options. 

Many  aspects  of  the  ope-atlon  of  the  system  cannot  be  brought  out  by  this 
kind  of  summary.  In  the  next  three  chapters,  I will  describe  its  knowledge 
more  systematically.  The  major  omission  so  far  has  been  a good  description  of 
the  task  network  and  its  evolution.  Uithout  this  description,  much  of  the 
content  of  the  rules  is  lost. 

To  compensate,  let  me  sketch  DESI’s  behavior  on  the  second  problem  I used 
as  an  example  in  Sect.  I. A,  indicating  points  of  interest  as  I go  along.  The 
problem  is  presented  as  the  problem  of  designing  a circuit  to  convert  signals 
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satisfying  an  input  predicate  to  those  satisfying  an  output  predicate.  (See 
Chapter  IV.)  This  is  uritten 

[DESIGN 
(X  (CKT) 

(CONVERT  ?DCT 
(X  (IN) 

lANO  (PERIODIC  (TFUN  ?IN)  10.0E-3) 

(FORALL  (T) 

(AMO  (-/>  C (/<  ?T  0) 

(-  ((ONE-PERIOO  (TFUN  ?IN))  ?T) 

D) 

(-/>  C (NOT  (/<  ?T  0)) 

(-  ((ONE-PERIOO  (TFUN  ?IN))  ?T) 

-im  ))  ) 

(X  (IN  OUT) 

(-  (TFUN  ?0UT)  (X  (T)  (SIN  (*  2000  PI  ?T))  ))  ))  )) 

The  input  predicate  is  just  a time-domain  definition  of  "IkHz  square  nave." 
The  output  predicate  defines  the  time  function  (TFUN)  of  the  output  to  be  a 
sine  uave.  (C  after  means:  to  prove  the  right-hand  side,  detach  the 

left  as  a subgoal.) 

The  design  problem  is  used  to  start  a task  network  or  plan.  The  goal  of 
the  problem  solver  is  to  accomplish  every  extant  task.  In  the  course  of  doing 
this,  subtasks  of  various  kinds  may  be  generated,  which  must  be  gotten  rid  of. 

In  the  case  at  hand,  the  complicated  design  problem  does  not  match  any 
stored  subplan  directly.  The  resulting  failure  of  the  theorem  prover  causes 
the  NASL  interpreter  to  set  itself  the  task  of  "rephrasing"  the  design  task. 


d 
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design . . . 

rephrase 
super- task 


explode 
design  ' 
property 


find  d -features 


find  cx)re 
O device 

/^find 

^ constraints 


make 
P)  design 
^ subnet 


Figure  1.10  A Rephrasing  Subtask 

This  rephrasing  process  notices  the  conversion  problem  in  the  description 
of  the  desired  circuit,  and  spends  some  time  trying  to  calculate  and  compare 
the  frequency  spectra  of  the  input  and  output  signals.  This  process  results 
In  the  re-descr  I pt  i on  of  the  problem  as  a low-pass  filtering  problem.  (The 
compleK  details  of  this  example  are  described  in  Chapters  IV  and  V.) 

This  operation  of  rephrasing  the  original  problem  is  carried  out  hy  the 
NASL  interpreter,  operating  at  a different  logical  level.  In  particular,  its 
behavior  is  rule-governed  in  the  same  way.  The  only  difference  is  that 
problems  at  the  lower  level  become  objects  of  manipulation  at  the  higher 
level.  The  result  of  this  manipulation  ultimately  appears  as  a new  problem 
network  at  the  original  level. 

The  signal  descriptions  I showed  earlier  are  subject  to  rules  from  ZORCH 
which  suggest  looking  at  them  in  the  frequency  domain  (Figs.  1.5  and  I.BI,  and 
looking  for  a simple  transformation  between  them.  The  transformation 
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discovered,  namely  ILOU-PASS  1000],  generates  the  design  shards 

l>  (CKT)  tDEV-TYPE  ?Cia  LOU -PASS -FILTER)) 

[X  tCKT)  (-  (LOU-CUTOFF-FREQ  ?CKT)  1000)] 

uhich  in  turn  suggest  a basic  device  type  (lou-pass  filter),  constrained  to 

reduce  its  output  at  all  frequencies  above  1 kHz  to  negligible  values. 

The  task  net  has  now  been  "elaborated"  to  the  structure  of  Fig.  1. 11. 


design... 


make  a ^ ^ constrain 

low-pass  O • O it  -- 

filter 


Figure  1.11  Rephrased  Task  Network 

The  problem  has  become  "make  a low-pass  filter,  and  constrain  it  to  fit  the 
exact  desired  characteristics."  The  first  subproblem  in  this  structure  Is 
much  simpler  than  the  original,  and  results  in  the  retrieval  of  a useful  plan, 
in  the  form  of  a "devfce  schema"  for  an  RC  filter.  (]  will  defer  the 
possibility  of  more  than  one  schema  being  brought  to  mind  until  later.) 
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make 

low- pass  ^ 


O Constrain 
selectivity 


Get  ^ 
an  RC  O 


Q select  R 
O select  C 


"Frozen  constraints" 
on  R,  C,  and  System  Function 


Figure  1.12  Retrieved  Circuit  and  Constraint  Task  Netuork 
The  problem  nou  (see  Fig.  1.12)  is  to  satisfy  the  constraints  given.  Some 
of  these  came  uith  the  problem  statement,  but  many  more  tag  along  ui  th  the 
schema  for  RC  filter  (which  includes  facts  about  filters  in  general).  A 
useful  feature  of  the  NASL  language  is  that  we  can  express  the  purposes  of 
devices  in  the  same  language  the  system  uses  to  express  its  own:  as  tasks.  To 
use  an  RC  filter  is  to  insist  that  its  resistor  and  capacitor  have  values 
compatible  with  its  desired  system  function.  Such  tasks  are  called  "frozen 
policies. " 

Such  already  established  tasks  are  not  the  only  useful  kind  that  ride 
along  in  device  schemata.  There  are  also  "expansion  obligations"  which  remain 
to  be  done.  An  example  of  this  technique  is  the  definition  of  "active 
transistor,"  as  a "raw"  transistor  plus  the  commitment  to  bias  it  in  whatever 
context  it  appears.  In  the  case  of  the  filter,  the  only  expansion  obligations 
are  to  select  values  for  the  primitive  components.  These  tasks  (see  Fig. 

1.12)  are  carried  out  by  interactions  with  the  new  and  frozen  constraints. 
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(In  the  current  implementation,  most  algebraic  symbol  manipulation  is  carried 
out  by  the  human  user.)  Values  are  to  be  found  which  satisfy  all  the 
constraints.  Uhen  they  are  found,  the  fact  that  they  satisfy  the  constraints 
is  to  be  "protected.”  (Sussman,  1975)  This  can  be  a complex  task  in  itself. 
(Chapter  III.) 

As  we  saw  before,  there  are  no  values  which  satisfy  all  the  constraints. 
Even  for  engineering  purposes,  an  RC  filter  cannot  quite  do  the  job.  In  this 
case,  a failure  occurs,  which  causes  the  insertion  into  the  network  of  a 
correction  task.  This  task  may  have  to  edit  the  task  network  as  well  as  (he 
current  circuit  model  in  order  to  solve  the  design  problem  adequately.  (The 
current  implementation  stops  before  this  point.) 

I have  glossed  over  the  problem  of  choice  in  this  example.  It  is  more 
obviously  relevant  in  the  case  of  the  first  example  of  Sect.  I.A,  designing  a 
buffered  amplifier.  In  this  case,  rephrasing  is  relatively  simple,  being  a 
matter  of  unpacking  a lambda  expression  such  as 

IX  (X)  (ANO  (DEV-TYPE  ?X  AnPLIFlER) 

(-  (V-GAIN  ?X)  5) 

(-  (INPUT-R  ?X)  300001)1. 

However,  these  fragments  suggest  more  than  one  kind  of  amplifier,  as  we  saw. 
(Fig.  1.2)  In  other  words,  the  system  has  converted  a problem  with  no 
apparent  solutions  into  a problem  with  two  apparent  solutions.  This 
embarrassment  of  riches  is  handled  by  invoking  the  choice  mechanism,  a simple 
"protocol"  for  calling  the  theorem  prover.  In  this  mode,  a series  of  staccato 
deductions  are  made  which  attempt  to  rule  out  alternatives,  vote  in  favor  of 
alternatives,  or  synthesize  new  ones.  (See  Chapter  2.)  The  relevant  rule  is 
the  one  that  says,  "if  you  are  trying  to  choose  among  different  ways  of  making 
an  amplifier,  and  option  1 was  suggested  because  of  its  input  resistance,  and 
option  2 for  some  other  reason,  replace  these  options  with  (CASCADE  [option  1| 
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loption  2|1."  (A  simplified  version  of  this  rule  appears  above. I 

Other  choices  that  occur  in  these  examples  are  handled  similarly.  There 
is  a rule  that  the  general  common-emitter  circuit  is  the  starting  point  for 
implementing  a common-emitter  coupled  to  something  else.  In  the  second 
example  problem,  if  the  system  is  ever  told  about  LC  filters,  ue  will  also 
have  to  give  it  rules  like 

"Use  an  LC  filter  if  the  power  involved  is  high." 

"Other  things  equal,  don’t  use  an  inductor  circuit  if  you  can  help  it." 

For  OESI’s  actual  behavior  on  these  problems,  see  Chapter  V. 

1. 0 Relation  to  Previous  Work 
1.0.1  Problem  Solving  and  Reasoning 

The  problems  I am  attacking  in  this  research  are  not  new.  The  problems  of 
generality  vs.  expertise  were  originally  studied  by  Allen  Newell  and  his 
coworkers  around  19G0.  INewell,  1962)  Their  efforts  produced  a "General 
Problem  Solver"  which  we  have  been  trying  to  debug  ever  since.  lErnst  and 
Newell,  1969)  GPS  was  a "means-ends  analysis"  problem  solver  which  applied 
state  transformation  operators  to  bring  it  to  its  goal.  McCarthy  I19S9)  gave 
us  the  term  "advice  taker"  to  describe  a program  which  can  take  new 
Information  and  use  it  to  do  better.  The  creation  of  such  a program  is  still 
my  long-term  goal  and,  in  a sense,  that  of  most  other  researchers. 

Uhi  le  this  research  was  in  progress,  a tide  of  "rule-based"  AI  programs 
has  risen  which  NASL  seems  to  be  a part  of.  Its  ancestors  are  the  systems  I 
described  in  Sect.  I.B,  More  recent,  special-purpose  rule-based  systems  have 
sought  to  overcome  their  limitations.  Shortliffe’s  (1976)  MYCIN  is  a limited 
but  elegant  medical -diagnosis  system  which  uses  a backward-chaining  deductive 
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systent.  Susaman  and  Stallman's  (1975)  EL  does  electronic  circuit  analysis  by 
forward  deduction.  Both  of  these  systems  keep  a record  of  deductions.  EL 
uses  these  records  to  rethink  deductions  based  on  unworkable  assumptions. 
(Stallman  and  Sussman,  197GI  Both  systems  use  them  to  explain  their  derluctions 
to  a human  user. 

The  NASL  system  differs  from  these  in  that  its  control  language  is  aimed 
at  a higher  level  of  abstraction.  Its  rules,  expressed  in  a predicate 
calculus,  specify  conclusions  rather  than  actions.  Action  is  achieved  by 
having  certain  conclusions  be  interpreted  as  "required  tasks"  by  the  action 
interpreter.  The  notion  of  "task"  is  intended  to  be  very  inclusive. 

HYCIN  and  NASL  can  both  be  given  new  rules,  which,  if  they  are  not  buggy, 
interact  with  the  rest  of  the  system  in  efficient  ways.  However,  MYCIN’s  rule 
language  is  deliberately  restricted  to  the  domain  of  fault  diagnosis  in  poorly 
understood  systems.  (Davis  et.  al.,  1975)  (flYCIN  is  superior  to  NASL  in 
having  a more  developed  procedure  for  graceful  assimilation  of  new  rules. 
(Davis,  197B) ) EL’s  rules  have  stylized  LISP  code  bodies.  They  can  do 
anything,  in  principle,  but  the  system  functions  most  elegantly  when  organized 
around  the  satisfaction  of  numerical  constraints.  flYCIN  does  almost  entirely 
backward  chaining  during  deduction;  EL,  forward  chaining. 

The  most  important  conceptual  problem  I have  found  in  working  on  NASL  is 
the  requirement  that  the  control  structures  of  a problem  solver  ought  to  be 
simple  enough  to  be  inspectable,  but  contain  enough  higher-level  concepts  to 
be  useful  when  inspected.  The  HYCIN  group  express  this  as  a demand  for 
"stylized  programming"  (Davis  et.  a?.,  19751.  They  have  achieved  impressive 
results  in  two  areas.  First,  by  use  of  "meta-rules,"  their  diagnostic  program 
can  guide  its  own  flow  of  control.  This  is  something  like  my  "choice 
protocol"  in  which  NASL  uses  choice  rules  to  decide  how  to  proceed.  Second, 
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their  knou I edge-acqu i 9 i t i on  program  knows  enoi/gh  about  the  " 9 ty I i za t i on"  to 
participate  in  writing  anri  debugging  new  rules.  I shall  mal"  o a more  detailed 
comparison  of  these  two  capabilities  with  actual  and  potential  abilities  of  my 
program  in  Chapter  VI. 

The  main  limitation  of  flYCIN's  style  of  rule-based  programming  is  that  it 
is  wholly  oriented  toward  making  tests  and  letting  them  "cast  votes"  fnr  a 
result.  There  Is  no  concept  of  planning  or  even  acting.  Davis  et.  al . 

(1975)  acknowledge  that  for  a domain  with  a more  precise  theory  than  medical 
diagnosis,  a different  control  structure  is  called  for.  1 hope  DESI  is  an 
examp I e. 

Stallman  and  Sussman’s  (197S)  EL  is  implemented  using  a language  called 
ARSE  which  is  embedded  in  LISP.  The  primitives  in  ARSE  implement  a system  of 
forward  deduction  and  "guessing,"  aimed  toward  finding  a consistent  assignment 
of  variable  values  in  a constraint  network.  ARSE  has  been  used  experimentally 
on  other  tasks  involving  constraints  (flason,  197G,  Doyle,  197G).  and  so  has 
modest  pretensions  to  generality.  ARSE's  control  structure  is  formally  close 
to  NASL’s  (and  helped  inspire  it).  ARSE  maintains  "rlemon  queues"  generated  by 
ongoing  deductions.  However,  EL  lacks  the  need  or  power  to  inspect  these 
queues  efficiently.  NASL  embeds  the  control  structures  in  an  associative  data 
base,  and  generalizes  the  notion  of  queue  to  a task  network. 

In  this  respect,  the  closest  control  structure  to  NASL  is  Sacerdoti’s 
(1975)  NOAH.  This  is  a brilliant  program  for  planning  a mechanical  assembly 
and  advising  a person  carrying  it  out.  The  planning  part  constructs  a 
hierarchical  network  of  ever  more  detailed  plans.  These  plans  are  not 
programs;  in  particular,  they  do  not  have  to  be  totally  ordered.  As  parts  of 
the  plan  are  expanded,  their  interactions  with  each  other  are  noted  and 
corrected  for  by  enforcing  orderings. 
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The  main  difference  between  this  part  of  NDAH  and  NASI  is  that  NOAH  is  a 
pfan  compiler,  while  NASL  is  an  interpreter;  that  is,  it  expands  and  executes 
pieces  of  plan  as  it  goes.  This  is  necessarg  because  NOAH  has  a simple 
STRlPS-liKe  (Pikes  and  Nilsson,  1971)  assumption  about  actions  which  NASI 
doesn’t  share.  In  particular,  NASL  is  not  as  sanguine  as  NOAH  about  expanding 
a future  action,  because  it  has  a limited  model  of  the  world  at  that  point. 

It  does  not  attempt  to  summarize  the  effects  of  all  tasks  as  state  changes,  so 
it  cannot  have  a doma i n- I ndependent  algorithm  for  ctiecking  interactions 
between  steps.  In  particular,  actions  like  "Design..."  and  "Constrain...." 
whose  effects  depend  on  how  they  are  carried  out  and/or  what  else  is  Iming 
executed,  do  not  fit  into  Sacerdoti’s  framework.  This  makes  room  for  more 
sophisticated  knowledge  about  action,  but  it  is  a pity  that  I cannot  use 
Sacerdoti’s  simple  and  (within  their  limits)  powerful  algorithms. 

I have  also  profited  from  reading  papers  by  Nilsson  (1973)  and  Philip 
Hayes  11975)  on  Interleaving  planning  and  execution.  Several  researchers 
(Schank  and  Abelson,  1975.  Abelson,  1975,  Rieger,  1976,  Charniak,  1975)  have 
done  research  on  class!  f icat  ion  of  plans  analogous  to  my  taxonomies  of  Chapter 
II.  Usually,  however,  they  have  been  more  concerned  with  analyzing  narratives 
than  with  actually  solving  problems,  which  has  led  to  different  criteria  for 
classification.  Perhaps  some  synthesis  of  these  apfiroaches  will  be  possible. 

A class  of  systems  with  which  NASL  shares  certain  properties  are  the 
"utility"  AI  systems  which  have  appeared  recently.  These  are  systems  which 
provide  data  and  control  representations  for  users,  who  are  expectetl  to  use 
these  facilities  for  prob  I em-spec  i f i c programs.  Examples  are  the  AI  languages 
iRobrow  and  Raphael,  1973),  Bobrow  and  Uinograd’s  (1976)  "Knowledge 
Ret'r esen t a t i on  Language."  and  Srinivasan's  (1976a, hi  "Meta  Description 
System."  The  AI  languages  provide  assertion-based  data  bases  like  NASL’s. 
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(NASL  and  STP  are  descended  in  this  direction  from  the  A1  languarje  Conniver. 
(Sussman  and  McDermott,  197211  The  other  two  systems  are  more  semantic-network 
oriented.  (Uoods,  1975)  This  is  in  many  ways  merely  a formal  difference. 
Other  differences  between  these  research  efforts  depend  on  healthy  differences 
of  focus.  For  example,  the  KRL  group  is  more  concerned  with  recognition 
problems  than  1 have  been. 

A bigger  philosophical  difference  is  that  NASL  is  an  attempt  to  provide  a 
plan  description  language  rather  than  a programming  language.  The  distinction 
may  be  wholly  metaphysical;  however,  1 believe  that  several  features  of  NASL 
plans,  especially  the  notion  of  “policy,"  if  implemented  properly,  belong  to 
plan  description  rather  than  programming,  A concrete  distinction  between  NASL 
and  the  traditional  "A1  utility"  IHewitt,  1972)  is  that  NASL,  far  from 
requiring  a program  to  specify  a piece  of  knowledge,  requires  a borly  of 
knowledge  to  specify  a program.  I believe  that  Srinlvasan's  MOS  results  from 
a similar  orientation,  but  he  is  more  concerned  with  general  puzzle  solving 
than  capturing  the  knowledge  in  a rich  domain. 

In  any  case,  the  older,  less  pretentious  AI  languages  are  the  only  members 
of  this  list  of  systems  (NASL  included)  which  are  mature  enough  for  their 
flaws  and  strengths  to  be  visible.  Which  features  of  the  newer  systems  will 
endure  remains  to  be  seen. 

Unlike  most  of  the  problem  solvers  mentioned,  NASL  uses  a theorem  prover 
to  do  sophisticated  deductive  information  retrieval.  This  use  of  theorem 
provers  has  been  suggested  by  many  people.  (Travis  et.  a).,  1972,  Darlington, 
19G9,  Moore,  1975)  My  theorem  prover,  STP,  resembles  most  closely  that  of 
Nevins  (197Aa),  with  features  from  the  work  of  Bledsoe  (1975)  and  Ernst  (1971, 
1973).  Those  familiar  with  the  theorem-proving  literature  will  enjoy  Appendix 
A,  which  describes  its  features. 
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Other  people  h;ive  studied  someuhat  different  uses  of  theorem  provers  in 
problem  solving.  (E.g.,  Fikes  and  Nilsson,  1371  I In  the  past  couple  of  gears, 
one  group  of  people  has  been  urging  the  use  of  a predicafe-calculus  theorem 
prover  as  the  only  interpreter  of  a problem  solver.  (KoualsKi,  1973,  1976, 
Uarren,  1974,  Hages,  1973b,  Tarnlund,  19751  I think  this  vieu  is  misguirfed. 
Generally  one  does  not  go  very  far  uith  this  approach  before  he  starts  aditing 
corruptive  features,  such  as  ordering  the  axioms,  putting  in  dummy  prerlicates 
to  control  search,  allowing  rules  to  refer  to  formulas,  etc.  (Uarren,  1974) 

My  conclusion  was  that  it  is  better  to  admit  defeat  from  the  start,  so  1 put 
control  features  in  as  concepts  manipulable  by  the  calculus  and  def  inert  by  the 
interpreter,  and  tried  to  preserve  some  of  the  purity  of  the  theorem  prover 
itself.  I shall  have  more  to  say  about  the  success  of  this  attempt  in  the 
cone  I us i on. 

I should  mention  that  the  concepts  of  action  and  decision  have  concerned 
philosophers  for  hundreds  of  years.  Recently,  a whole  branch  of  analytic 
philosophy  has  sprung  up  around  them.  (Langford,  1971,  Rrand,  1970,  Danto, 
1965,  Goldman,  1970)  Many  of  the  workers  in  this  (ield  have  interesting 
things  to  say  about  the  logic  of  action.  For  example,  the  computer 
scientist’s  notion  of  a "primitive"  is  reflected  (somewhat  dimly)  in 
statements  like,  ”...  those  actions,  ...  performed  by  M,  which  he  cannot  be 
said  to  have  caused  to  happen  ,..  I shall  designate  as  basic  actions."  (Canto, 
1965)  Unfortunately,  these  philosophers  are  mucti  too  reluctant  to  imagine 
that  the  mind  behaves  like  a device  with  a real  structure:  all  of  their 
definitions  are  in  terms  of  phenomenological  rather  than  technological 
categories.  For  example,  Goirtman  (19701  gives  ftie  following  exegesis  of  ttie 
notion  of  "basic  action";  A basic  act  is  an  act  A such  that  "if  S wanted  to 
exemplify  A (at  t),  he  would  exemplify  A (at  t)."  He  then  must  spend  no 
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little  effort  eKplainlng  auay  paralytics.  1 think  that  in  the  I oncj  run 
philosophers  eKposect  to  AI  ideas  are  most  likely  to  arrive  at  useful  cnrtcepts 
in  this  field  by  explaining  "want"  and  "act"  in  terms  of  hypothesized  internal 
constructs. 

I.D.2  Electronics  and  Design 


The  usual  problem  domain  for  a researcher  with  my  pretensions  is  some 
class  of  puzzles  (Ernst  and  Neuell,  19G9)  or  "narrative  understanding." 
(McOermot t , 197Aa,  Charniak,  1972).  I have  chosen  elementary  electronic 
circuit  design  instead,  for  these  reasons: 

(1)  It  is  not  as  broad  and  sloppy  a domain  as  "story  understanding."  One 
can  reach  "critical  mass"  with  a data  base  much  taster.  There  are  clearof 
criteria  for  success.  Electronics  involves,  I hope,  as  few  mental  competences 
as  possible  in  an  interesting  domain. 

(2)  On  the  other  hand,  there  is  room  for  a variety  of  kinds  of  knowledge. 
The  domain  cannot  be,  and  doesn’t  have  to  be,  represented  fully  by  a state 
space  and  a set  of  operators.  Puzzles  are  both  too  easy  and  too  hard  at  once; 
they  are  probably  a misleading  example  of  problems  that  succumb  to  human 
think i ng. 

13)  The  subject  matter  is  already  formalized  to  some  degree,  so  that  I can 
focus  on  formalizing  the  control  knowledge  that  Is  necessary. 

(A)  Electronics  is  simpler  than  other  engineering  domains  in  that  it 
requires  less  knowledge  of  space,  time,  and  motion.  Expertise  in  the«e  areas 
presumably  draws  on  innate  abilities  we  have  difficulty  bringing  to  light. 

(5)  My  research  has  had  the  benefit  of  being  part  of  an  ongoing  MIT  AI 
laboratory  project  in  automating  electronics  reasoning.  Concepts  used  l>y 
Sussman  and  Stallman  (1975),  Stallman  and  Sussman  (197G),  and  A,  Brown  (1975), 
have  been  taken  over,  sometimes  with  some  modification,  into  DESl's  knowledge 
base.  (This  is  especially  true  of  the  parts  concerned  with  signal  description 
and  electronic  analysis.) 

(6)  My  wretchedness  as  an  electrical  engineer  should  make  it  easy  to 
construct  a program  as  good  as  its  creator. 

The  main  drawbacks  to  electronics  are 

(1)  It  is  somewhat  inaccessible  to  the  average  AI  researcher  or 
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psychologist.  People  lose  interest  in  documents  regarding  something  they  know 

little  about.  (Uho  knows  what  OENORAL  (Buchanan  et.  n1.,  19B3)  really  floes?) 

I have  tried  to  keep  large  sections  of  this  text  independent  of  electronics. 

Only  Chapter  IV  and  Appendix  3 rely  on  it. 

(2)  Electronics  knowledge  as  presented  in  introductory  texts  leans  on 
spatial  representations  to  some  degree,  even  if  not  as  much  as  other  branches 
of  engineering.  Frequency-domain  manipulations  and  pole-zero  plots  are 
examples  of  this.  1 have  tried  to  preserve  the  structure  of  this  knowledge  in 
formal  expressions  (see  Chapter  IV),  but  I am  aware  that  humans  probably  use 
more  "wired-in"  modes  of  spatial  reasoning,  whatever  that  may  turn  out  to 
mean.  I doubt  that  one  could  choose  a better  domain  than  electronics  for 
avoiding  this  problem,  however. 


fly  knowledge  of  electronics  is  mainly  derived  from  books.  (Senturia  and 
Uedlock,  1975,  Hayt  and  Neudeck,  197B,  Uatson,  1970)  This  is  reflected  in  the 
fact  that  the  problems  DESI  has  been  exposed  to  are  "problem  set"  problems, 
not  the  sort  that  a technician  would  encounter  In  daily  practice. 

There  is  a large  literature  on  the  theory  of  design,  artificial 
intelligence  and  design,  and  "computer-aioed  design."  So  far,  however,  the 
intersection  of  these  fields  is  almost  empty.  Books  about  the  design  process 
(Alexander,  19G4,  Asimow,  19B2,  Buhl,  1962,  Glegg,  1973)  consist  mainly  nf 
advice  for  avoiding  overlooking  things  in  pondering  problems  and  working  out 
solutions.  About  proposing  solutions  to  start  with,  most  of  these  authors  say 
things  like  this: 

"Uhat  enables  us  to  draw  from  the  warehouse  of  our  experience  just  (he 
right  set  of  elements,  and  to  put  them  into  just  the  right  combination  so 
that  they  have  a sense  of  fitting  the  situation,  we  do  not  know,  since  no 
definite  solution  exists."  (Asimow,  19G2,  p.  45.) 

This  author  is  certainly  correct  that  we  do  not  know;  programs  like  DESI  are 

only  tiny  steps  toward  a theory  of  creativity.  Of  course,  as  a working 

hypothesis,  we  take  issue  with  the  claim  that  no  solution  exists. 

Design  has  attracted  ar t i f i c i a I - i nte I I i gence  researchers,  particularly  at 

Carnegie-Del Ion  University,  for  some  time.  Broadly  speaking,  areas  like 

automatic  programming,  and,  indeed,  all  problem  solving,  fall  under  the 
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heading  of  "design."  Houever,  the  theory  of  design  narrowly  construed  has 
been  explored  by  workers  like  Grason  (1970),  who  studied  resolution  of 
constraints  on  floor  plans;  Eastman  (19G8),  who  did  a formal  pychological 
study  of  performance  on  the  task  of  redesigning  a bathroom;  Haney  (19G8),  who 
studied  the  automatic  design  of  computer  instruction  sets;  and  Latombe  (137G), 
whose  rule-based  design  system  is  an  interesting  alternative  to  mine.  I have 
found  especially  useful  the  theory  paper  by  Freeman  and  Newell  (19G9)  on  a 
general  theory  of  design,  from  which  I have  borrowed  heavily.  (See  Chapter 
III.) 

One  might  expect  the  field  of  "computer-aided  design"  (CAD)  (Vlietstra  and 
Ulielinga,  1973,  Kuo  and  Oagnuson,  19G9,  Furman,  1970,  Rosenbrock,  1974)  to 
have  produced  many  expert  programs  for  a general  A1  program  to  compete  with. 
This  is  not  yet  the  case;  "CAD"  usually  has  little  to  do  with  the  automation 
of  the  actual  design  process,  but  concerns  itself  with  graphics  packages, 
analysis  prog'^ams,  and  other  interactive  aids  to  it.  For  example,  one  author 
distinguishes  "three  modes  of  (computer]  operation: 

(i)  Analysis,  An  engineering  situation  Is  specified  in  full 
mathematical  detail  by  the  designer,  and  the  computer  draws  certain 
further  mathematical  consequences..,. 

(ii)  Synthesis.  The  designer  specifies  in  detail  the  properties  which 
his  system  must  have,  to  the  point  where  there  is  only  one  possible 
solution.  The  computer  finds  this  solution.  An  example  is  optimal 
control . 

(iii)  Design.  This  is  the  creative  act  of  a designer,  guided  by 
calculations  on  the  computer  and  interacting  with  them  in  a sequential 
manner  to  produce  a satisfactory  solution."  (Rosenbrock,  1974,  p.  29) 

The  electrsnics  synthesis  tasks  to  which  comouters  have  been  put  include  very 

low-level  operations  such  as  printed-circuit  layout  (e.g.,  Fletcher,  1974)  and 

filter  design  (e.g.,  Chohan  and  Fidler,  1974).  The  approaches  taken  by  most 

people  in  this  field  are  usually  very  "mathematical,"  and  concentrate  on 

techniques  for  discrete  or  continuous  optimization.  For  example,  one  apiproach 
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to  circuit  design  in  the  literature  (Director,  1974)  con«ists  of  putting  in  as 
many  components  as  one  deems  plausible  and  letting  the  program  find  the 
optimal  component  values  for  the  task  given.  Many  of  these  components  will 
assume  null  values  and  "vanish”;  thus  this  approach  starts  with  a big  circuit 
and  finds  the  subset  that  does  the  job' 

CAO  is  only  beginning  to  become  aware  of  non-numer i ca I techniciues.  (But 
see  Powers,  1973.)  DESI  relies  almost  entirely  on  non-numer I ca I techniques, 
and  is  very  poor  at  constraint  resolution  and  component-value  opt  I m i /at i on.  A 
practical  system  would  have  to  combine  the  two  approaches. 

It  is  impossible  to  survey  this  field  in  detail  here.  It  includes  its  own 
journal.  Computer  Aided  Design,  and  supports  periodic  conferences. 
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II  Expressing  Knowledge  In  NASL 

The  heart  of  DESl  is  the  NASL  interpreter,  and  the  STP  theorem  prover 
which  it  drives.  The  theorem  prover  gives  the  system  a general  and  flexible 
notation!  the  interpreter  imposes  an  innate  interpretation  on  some  of  *he 
expressions  of  this  notation.  In  this  Chapter,  I ui  I | give  a discursive 
introduction  and  overview  of  the  interpreter,  describing  STP  and  other 
Inferentiai  protocols  as  they  come  up.  (See  Fig.  1. 9.) 

The  NASL  interpreter  is  a problem  solver  of  the  "problem  reduction"  type. 

i 

(Nilsson,  1971)  That  is,  it  solves  problems  by  reducing  them  to  simpler 

j 

subproblems.  The  differences  between  this  structure  and  a programming 
I language  are:  that  a problem  solver  must  decide  upon  the  order  in  which  to 

attack  subproblems;  that  a problem  solver  often  has  subproblems  of  the  form 
"reduce  problem  so-and-so,"  where  a programming  language  has  only  the 

subroutine  call;  and  that  a problem  solver  must  occasionally  choose  between 

I 

alternative  approaches. 

The  designer  of  a problem  solver  must  confront  the  problem  of  search.  For 

j problem-reduction  problem  solvers,  this  classically  takes  the  form  of  a search 

■ 

ij  through  an  AND/OR  graph  of  possible  approaches.  (Nilsson,  1971,  Fahiman,  1973, 

'j  McDermott,  1974a)  Uhether  the  search  strategy  is  depth-first  or  more  clever, 

j<i 

[f  it  depends  upon  being  able  to  save  and  restore  states  of  the  problem  solution 

and  hence  of  the  "world  model";  this  has  recently  tended  to  be  implemented 
using  a "context"  mechanism.  (Sussman  and  McDermott,  1972) 

I believe  that  searching  will  always  be  a part  of  Artificial  Intelligence 
technique.  However,  it  seems  to  me  that  search  among  alternative  sequences  of 
subproblems  and  world  models  is  a mistake.  My  principal  reason  for  this 
; belief  is  the  observation  that  in  the  normal  course  of  human  problem  solving, 

I 
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a rather  different  faculty  is  used  more  heavily,  namely,  the  ability  to 
correct  one's  errors.  The  difference  between  these  alternatives  is  this:  if  a 

"etate  of  the  world"  is  thought  of  as  an  internal  data  structure,  completely 
known  and  under  control,  it  is  just  as  easy  or  easier  to  return  to  an  earlier 
state  to  try  something  else  as  it  is  to  generate  a new  one.  But  if  states  of 
the  world  are  really  states  of  the  whole  world,  about  which  one’s  information 
is  limited  and  his  control  slight,  quite  the  opposite  is  the  case. 

So  the  question,  for  electronic  circuit  design,  is  whether  the  unfolding 
circuit  model  is  to  be  thought  of  as  an  internal  data  structure  or  as  a 
diagram  on  a piece  of  paper.  A little  reflection  on  this  choice  has  drawn  me 
to  the  second  alternative.  Since  useful  plans  will  ultimately  have  to  be 
applied  to  the  real  world,  whose  surprises  will  always  cause  mistakes  and 
revision,  the  problem  of  correcting  errors  rather  than  "popping  them  off  the 
context  tree"  will  have  to  be  faced  eventually.  There  is  no  point  in 
perfecting  a plan  down  to  the  last  detail  if  circumstances  will  wreck  it. 

This  is  probably  why  people  worry  so  little  about  producing  optimal  plans. 

If  search  isn’t  through  states  of  the  world  model,  but  it  is  necessary, 
what  is  it  that  is  searched?  I think  it  is  knowledge  about  courses  of  action. 
People  can  correct  states  of  the  world  created  by  the  wrong  plan,  but  they 
don’t  normally  do  this  as  a way  of  stumbling  on  the  right  plan.  Instead,  they 
use  knowledge  like 

"Under  circumstances  ...,  plan  ...  will  work." 

"If  ....  don’ t do  . . . . " 

Consider  the  difference  between  human  and  machine  playing  of  chess.  I 
will  assume  the  reader  is  familiar  with  the  usual  program  organization  around 
the  Idea  of  minimax  tree  search.  (Slagle,  1971)  A human,  by  contrast,  learns 
to  play.  His  initial  plan  is  simply  to  make  a legal  move,  wait  for  his 


a 


II  Expressing  Knowledge  in  NA5L 


US 


opponent's  reply,  and  repeat  this  until  the  opponent  wins.  As  time  goes  by, 
and  he  sees  and  hears  more  and  more  about  the  game,  where  does  he  put  what  he 
learns?  According  to  the  theory  I am  presenting,  it  becomes  part  of  the 
advice  surrounding  the  "make  a move"  step.  This  advice  is  usually  in  terms  of 
board  patterns,  phases  of  the  game,  etc.  Eventually,  more  sophisticated 
advice  in  terms  of  anticipating  possible  opponent  replies  is  assimilated.  If 
the  deductive  system  for  manipulating  this  advice  Is  adequate,  simple  tree 
searches  will  appear  as  a trace  of  its  manipulations.  But  this  will  never  be 
assimilated  to  the  overall  planning  level.  The  planning  level  does  not  become 
nondetermini st ic.  Instead,  what  begin  to  appear  there  as  the  player  becomes 
more  confident  of  his  powers  are  "game  plans,"  long-term  strategies  which 
influence  his  choice  of  moves. 

This  sort  of  search  through  knowledge  about  alternative  courses  of  action 
is  worth  spending  a lot  of  effort  on.  It  has  three  loci  in  the  NASL  system. 
The  principal  one  is  the  theorem  prover  STP.  (Sect.  II.B.2)  This  is 
supplemented  by  "choice  Information,"  (Sect.  II.C.l)  If  all  else  fails,  the 
system  calls  itself  recursively  to  "rephrase"  an  action.  (Sect.  II.C.2I  I 
have  worked  hard  to  make  these  devices  sophisticated.  I have  given  less 
thought  to  the  problem  of  undoing  mistakes  (Sect  II. E),  and  none  to  the 
question  of  learning  search  knowledge. 

Because  deductions  about  courses  of  action  are  so  central  to  the  theory, 
NASL  must  be  a language  for  describing  problems,  plans,  and  physics.  The 
categories  it  uses  for  descriptions,  and  the  inference  algorithm  it  can  call 
upon  to  manipulate  them,  determine  its  abilities  and  limitations.  The 
limitations  are  in  some  ways  as  important  as  the  abilities.  The  fewer  ways 
there  are  to  express  something,  the  more  likely  it  is  that  the  formulas 
related  to  it  will  be  noticed  during  rule  application,  and  the  more  flexible 
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and  extensible  the  system  uiill  be.  Conversely,  to  the  degree  that  each  user 
is  forced  to  maKe  up  his  own  control  conventions,  the  less  likely  it  will  be 
that  information  from  one  user  will  ever  affect  the  system's  approach  to 
problems  posed  by  another. 

NASL  is  not  a typical  programming  language,  since  the  user  can  intermix 
fragments  of  plans  and  axioms  governing  the  physics  of  problem  domains  with 
fully  developed  programs.  On  the  other  hand,  it  bears  a stronger  family 
resemblance  to  programming  languages  than  to  anything  else,  so  I have  included 
a "programmer’s  guide"  at  the  end  of  this  chapter  for  those  interested  in 
programming  in  NASL. 

1 1. A The  Natural  History  of  Actions 

The  fundamental  concept  implemented  by  the  NASL  interpreter  is  the  concept 
of  task.  A task  is  an  activity  to  which  the  interpreter  is  committed.  The 
basic  drive  of  the  interpreter  is  to  accomplish  all  the  pending  tasks. 

Examples  of  tasks  from  several  domains  are. 

"Put  Block  A on  Block  8." 

"Uait  here  for  five  minutes." 

"Put  the  male  chicks  in  this  box,  the  females  in  that  one." 

"Uin  the  war,  and  keep  the  peasants  happy." 

"Think  of  a fallible  Irishman." 

"Keep  your  promises." 

"Convince  yourself  that  all  equilateral  triangles  are  isosceles." 

In  electronic  design,  tasks  range  from  wiring  two  objects  together,  to 
designing  a hi-fi  system,  to  finding  a resistance  that  satisfies  a constraint. 

The  reason  for  the  broad  definition  is  my  goal  that  as  much  as  possible  of 
uhat  the  interpreter  is  doing  should  be  explicit,  so  that  reasoning  about  it 
can  be  shallow.  For  the  same  reason,  it  will  be  important  that  control 
information  be  expressed  in  a notation  compatible  with  everything  else.  So  I 
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represent  tasks  as  NASL  formulas  of  the  form 

(/:TASk  I name  I < -input  pvars-  > 

(X  ( -vars-  ) |action|  ) 

< -output  pvars-  >1 

Unfortunately,  I must  pause  here  to  describe  the  notation,  both  object  and 
meta.  NASL  formulas  are  aluays  enclosed  by  (brackets).  When  I am  describing 
a formula,  1 enclose  syntactic  variables  in  brackets  like  this:  or 

like  this:  The  second  kind  indicates  that  a sequence  of  syntactic 

constructs  is  uanted.  So,  for  example,  an  instance  of  a task  might  be  of  the 
form 

C/tTASk  (COUPLER  PLANW71)  <’ (BUFFER<(72)  ’(AnP»73)> 

(X  (STAGE!  STAGE2)  (COUPLE  7STAGE2  7STAGE1)  ) 

<• (CKT«74)>) 

This  describes  a task,  named  (COUPLER  PLAN<f71) , which  requires  taking  the  two 
circuits  [(AriP<f73))  and  ( (BUFFER#72) ) and  COUPLing  them  to  make  something 
which  will  be  called  I(CkT<f74)l.  (Notice  that  the  NASL  notation  permits 
tuples  of  objects  delimited  by  <angle  brackets>,  and  X-express i ons  to  express 
functions  and  predicates.)  /tTASk  is  a predicate  of  four  arguments.  It 
begins  with  the  prefix  which  indicates  that  it  is  a built-in  predicate 

used  by  the  interpreter  in  some  way.  A complete  catalogue  of  built-in 
predicates  and  functions  appears  in  Appendix  1. 

The  word  "pvars,"  for  "plan  variables,"  refers  to  terms,  such  as 
I (BUFFER<f72)  1 and  ((CKT<f74)),  which  are  sot  equal  to  calculated  quantities  in 
the  course  of  executing  tasks.  They  acquire  values  by  appearing  in  "rewrite 
rules"  of  the  form 

(•/>  ’ I term|  |value|) 

(Cf.  (Bledsoe  and  Tyson,  1975),  where  they  are  called  "reduction  rules.")  In 
my  example.  If  (-/>  ’ IBUFFER<(72)  DEV<f75I  and  (-/>  ’ (AnPi»73)  DEV«7B)  appear  in 
the  data  base  before  execution  of  the  task  ICCXJPLER  PLAN/K71),  DEV)f7G  and 
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OEVffJB  might  be  coupled  to  produce  DEVtf77{  then  the  interpreter  Mould  adtt  [-/> 
’ ICKT#74)  DEV#77I  to  the  data  base.  (For  an  explanation  of  the  single  quotes, 
see  Appendix  1 or  Sect.  II. 6. 2. 1 In  defining  actions  like  COUPLE,  I Mill 
indicate  their  outputs  uith  the  symbol  thus: 

(COUPLE  |ckt  1|  |ckt  2|]  ••>  <|neu  cktl> 
to  shoM  what  new  value  formulas  they  leave  in  the  data  base. 

Anyone  familiar  with  the  Al  languages  (Bobrow  and  Raphael.  1974,  Hewitt, 
1972)  will  recognize  the  concept  of  "present  in  the  data  base."  In  NASL, 
there  is  always  a current  "data  pool"  for  formulas  to  reside  in.  Formulas 
found  there  are  supposed  to  be  true;  those  absent  have  unknown  truth  values. 
(See  Sect.  II.B.  The  phrase  "data  pool"  is  meant  to  supersede  the  misleading 
word  "context."  (fIcDermott  and  Sussman,  1973,  Rulifson  et.  a).,  19721) 

This  notion  of  task  already  embodies  a complexity  not  found  in  the  action 
languages  of  Sacerdoti  (1975)  and  others  (Sussman,  1975),  namely,  that  tasks 
will  not  be  fully  specified  until  their  input  pvars  are  known,  and  that  tasks 
can  compute  values  to  be  used  by  subsequent  actions.  It  will  be  seen  that 
this  broadens  the  scope  of  the  action  system  considerably,  while  making  future 
actions  harder  to  analyze.  It  seems  essential  for  automating  design. 

Ulth  just  this  much  machinery,  plus  a simple  forward  deduction  scheme,  we 
have  a notation  similar  to  that  of  a production  system  (Newell,  1973a, 

Rychener , 197G).  For  example,  we  might  have  a deductive  rule  that  says 

C (DEV-TYPE  ?A  COnnON-EmTTER) 

D 38(/:TASk  ?B  <>  (X  0 (BIAS  ?A) ) <>)), 

meaning,  "Every  common-emitter  amplifier  must  be  biased."  (I  have  introduced 

standard  logical  notation  for  implication  and  quantifiers.  (Suppes,  1957) 

Variables  are  prefixed  by  "?";  free  variables  are  supposed  to  be  universally 

quantified.  The  Internal  notation  for  implication  will  be  explained  below.) 


A 


d 
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This  rule  is  analogous  to  a production  in  having  a condition  on  the  (e<t  and 
an  action  on  the  right,  but  it  differs  in  certain  crucial  uays. 

First,  ue  are  not  limited  to  condition-action  pairs.  The  more  basic  case 
is  "condition-condition."  This  enables  us  to  treat  deductive  information 
retrieval  as  a process  distinguishable  from  plan  execution.  It  can  tie 
optimized  separately,  using  techniques  specific  to  the  kind  of  search  that 
arises  during  deduction.  (tloore,  1975,  Fahiman,  1975bl  Pore  important,  since 
the  system  knous  uhen  it  is  doing  deduction,  and  uhen  action,  it  can  keep  more 
revealing  records  for  use  in  choosing  courses  of  action,  explaining  uhat  it 
did,  and  recovery  from  errors.  (In  the  future,  such  records  could  be  iispd  for 
careful  assimilation  of  neu,  possibly  unreliable,  information.  Cf.  (Davis, 
197G,  HcOermott,  l‘97Aa)  . By  contrast,  since  the  meaning  of  a condition-action 
pair  depends  entirely  on  the  meanings  (some  deductive,  some  notl  given  to 
symbols  by  the  behavior  of  the  rest  of  the  system  as  a uhole,  it  is  impossible 
to  say  uhether  a neu  rule  of  this  kind  is  "correct"  uithout  extra  commentary.) 

Second,  deducing  /:TASKS  before  executing  them  gives  an  extra  layer  of 
"carefulness"  to  the  system.  (Cf.  (Sussman,  19751,  uhere  the  term  "careful 
mode"  is  introduced.)  A task  is  aluays  noted  in  the  current  data  pool  before 
being  executed.  Here  it  can  trigger  other  tasks  or  be  available  for  other 
deductions.  Furthermore,  the  system  can  note  a task  some  time  in  advance  of 
when  it  actually  decides  to  do  it.  For  example,  a task  can  appear  before  its 
pvars’  values  are  knoun.  Pore  generally,  a formula  of  the  form 
t/:SUCCESSOR  |task  name  l|  jtask  name  2|) 
must  mean  that  task  2 is  to  be  postponed  until  task  1 has  been  "begun"  (in  a 
sense  explained  below).  In  this  way,  a network  of  tasks  linked  by  /rSUCCESSOR 
relations  and  variable  flows  is  created  (which  the  interpreter  will  munch 
"from  left  to  right";  cf.  Fig.  II. II. 
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^acquire  speaker  Q 


o 


connect  them 


■^acquire  amp^ 


^ verify  that  the 
LJ  assembly  works 


o 


bias  it 


^enabled  tasks 


Figure  II. 1 A Taek  Net,  or  "Plan" 

Final Ig,  a tgpical  product ion-egetem  action  is  aluags  a primitive  ttiat  can 
be  carried  out  immediateig,  uhile  eome  NASL  taske  require  must  be  broken  doun 
into  subtasks  in  order  to  be  executed.  This  requirement  is  uhat  makes  NASL  a 
problem  sol'^er.  In  other  words,  a task  can  be  as  much  a part  of  the  problem 
as  of  the  solution;  it  looks  like  part  of  the  solution  to  its  superiors,  and 
part  of  the  problem  to  Its  subtasks. 

' Thus,  a task  (or  action)  is  either  primitive  or  problematic.  An  action 

mag  be  primitive  in  two  wags.  It  can  have  a LISP  program  for  carrging  it  out, 
or  it  can  have  a set  of  model  manipulation  statements  that  hold  true  of  it. 
These  statements  are  the  same  as  STRIPS's  add-  and  de  I e t e- I i s t s.  (Pikes  and 
.Nilsson,  1971)  Theg  are  sufficient  to  represent  completeig  onig  the  simplest 
of  actions,  but  theg  make  these  actions  easg  to  reason  about.  (Cf.  Sacerdoti. 
1975) . 

A problematic  task  must  be  "reduced"  to  one  or  more  subtasks.  This 
relation  between  tasks  is  expressed  bg  formulas  of  the  following  sort: 
I/iSUBTASIC  Isubtask  name)  Isupertask  name|l 
A task  can  be  the  subtask  of  more  than  one  super  task. 
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Task  reduction  can  occur  in  more  than  one  uay.  The  derluctlve  system  can 
infer  a complete  set  of  subtasks  of  a task  in  the  course  of  forward  rledurtion. 
However,  this  fails  to  give  enough  direction  or  power  to  the  prob  I em-r  erluc  t i on 
process.  As  described  in  Section  II. B,  the  interpreter  must  have  the  concept 
of  one  action  being  a way  of  carrying  out  another,  expressed  like  this: 

I/:  TO-DO  I task  name]  |action|  < -output  pvars-  > |method|l. 

This  is  Intended  to  mean  that  the  method  is  an  effective,  feasible,  and 
permitted  way  of  accomplishing  the  task  consisting  of  the  action.  Such 
statements  can  be  used  in  the  creation  of  subtasks. 

The  "method"  to  which  a task  is  reduced  may  consist  of  a single  action,  or 
it  may  be  a "macro  action"  which  stands  for  an  entire  subnet  of  new  tasks. 

This  requires  the  notion  of  a plan  schema,  an  abstract  object,  instances  nf 
which  may  be  thought  of  as  hanging  as  little  subnets  off  nodes  in  the  task 
network.  (Fig.  II. 2)  The  manipulation  of  instances  of  these  schemata  is 
described  in  Sect.  II. B. 1.2.1. 
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Figure  11.2  Task  Network  with  Subnets 
Thus  tasks  may  be  classified  according  to  whether  their  actions  are 
primitive  or  problematic.  These  classifications  form  one  of  the  taxonomies 
shown  i n F i g.  I 1 . 3. 


i 


d 
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Problemat icity 

Pr  i tn  i t i ve 

Model  manipulator 
Macro 

Primitive  po I i eg 
Problemat ic 

Monas 1 1c  ism 

Inferential 
Uor Idly 

Parasitism 

Pr i mary 
Secondary 

Figure  11.3  Logical  Taxonomies  of  Tasks 
The  other  two  taxonomic  classifications  are  independent  of  this  one.  One 
classifies  tasks  according  to  "monast ici sm. " Every  task  is  either 
Inferential,  in  which  case  it  consists  of  inferring  formulas  from  other 
formulas  supposed  to  be  true;  or  "worldly,"  when  it  or  some  of  its  subtasks 
perform  model  manipulations.  This  classification  is  expressed  by  means  of  the 
predicate  /INFERENTIAL. 

The  last  taxonomy  is  the  important  classification  by  "parasitism."  A task 
is  either  primary,  meaning  that  it  has  steps  to  be  pursued  in  order;  or 
secondary,  meaning  that  its  "execution"  amounts  to  influencing  or  monitoring 
the  execution  of  primary  tasks.  Ongoing  secondary  tasks  are  somewhat 
grandiosely  called  "policies,"  How  they  are  handled  is  described  in  Sect. 

II.B.  Some  representative  classes  of  policies,  expressed  in  English,  are 

"Wait  until  ...  is  true." 

"Notice  if  formula  ...  is  removed." 

"Take  into  account  desired  feature  ...  of  the  device  you  are 
designing. " 

"Constrain  quantities  ...  to  satisfy  ..." 


d 
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Policies,  like  primarg  tasks,  may  be  primitive  or  problematic,  worldly  or 
Inferent iai . 

A policy  may  have  a scope,  which  is  the  primary  task  whose  execution  (or 
whose  subtasks’  execution)  it  is  intended  to  influence.  As  you  might  expect, 
this  is  indicated  thus: 

l/:SC0PE  I secondary  task  name|  {primary  task  name  1 1 
Policies  do  not  outlive  their  scopes.  In  drawing  task  networks.  I will  put  a 
little  cloud  around  a task  to  indicate  that  it  is  the  scope  of  one  or  more 
policies;  the  policies  will  be  tied  to  these  clouds  with  a line.  (Cf.  Figs. 

1 1 1.7  and  1 1 1.8.) 

There  is  no  mystery  to  ttie  notion  of  policy.  AM  computer  programs  embody 
policies;  the  particular  data-base  and  interrupt  mechanisms  I use  to  implement 
them  are  commonplace  in  AI  applications.  The  novelty  is  that  the  notion  has 
been  made  explicit,  and,  in  a modest  sense,  put  into  the  logical  calculus. 

This  prevents  two  problems  with  the  usual  use  of  the  implementation 
mechanisms.  First,  typical  Al-language  "demons"  (Charniak,  1972)  fire  off  in 
the  middle  of  primitive  data-base  operations  and  get  complete  control  of 
^ operations.  Without  conventions,  it  is  difficult  for  other  processes  to  know 

I 

I what  the  intentions  of  these  little  monsters  are. 

I 

I 

I Second,  policies  are  to  be  used  to  express  things  (ike  "loop  invariants" 

j and  "program  assertions"  (Floyd,  1967),  which  are  usually  extraneous  to  actual 

I program  text  and  only  indirectly  related  to  individual  program  steps.  But  a 

\ problem  solver  has  need  of  the  notion  of  a "partially-reduced"  problem,  some 

, of  whose  subtasks  have  not  been  fully  reduced  to  primitives.  This  is 

difficult  to  capture  without  the  concept  of  a policy.  For  example,  consider  a 
program  to  count  the  prime  numbers  in  a table.  The  text  of  the  program 
contains  instructions  to  initialize  a counting  variable  and  inc-ement  it  just 
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after  a prime  number  has  been  discovered.  The  purpose  of  this  variable  may  be 
expressed  by  an  invariant  of  the  form  "x  is  the  number  of  primes  in  the  part 
of  the  table  already  looked  at."  Uhat  I am  trying  to  capture  is  the  notion  of 
an  early,  unfinished  version  of  the  program,  in  which  the  pieces  of  text  do 
not  yet  exist,  and  the  invariant  is  ail  there  is. 

A plan  is,  in  a sense,  this  kind  of  unfinished  program,  with  the 
difference  that  it  gets  executed  without  ever  getting  completely  written. 
Comments  on  a plan  are  not  there  to  explain  an  existing  text  or  to  help  prove 
that  it  works;  they  are  there  to  explain  an  ongoing  course  of  action,  and  they 
must  be  executable.  Their  individual  steps  may  indeed  involve  initialising 
and  incrementing  counters:  these  will  become  subtasks  of  the  policy. 

I will  conclude  this  section  by  listing  some  limitations  of  this  plan 
calculus.  These  fall  into  two  categories:  bad  limitations  and  good 
I imi tat  ions. 

The  bad  limitations  are  those  due  to  the  fact  that  I knew  the  plan 
language  was  going  to  be  used  for  designing  and  1 didn’t  have  the  time  to 
implement  unnecessary  features.  So  i didn’t  put  in  features  such  as  other 
agents’  plans,  or  notions  like  "prerequisite  of  an  action."  These  and  other 
inadequacies  are  described  at  slightly  greater  length  in  Chapter  VI. 

The  good  limitations  are  those  arising  from  these  goals: 

(1)  Deductions  about  plans  ought  to  be  simple  and  shallow. 

(2)  New  knowledge  must  be  expressed  in  a notation  compatible  with  old. 

By  deductions  about  plans,  I mean  deductions  about  current  plans,  not  "proofs 
of  plan  properties."  (Cf.  Sect.  VI. C)  It  ought  to  be  easy  to  deduce  what  you 
are  doing.  Otherwise,  the  executions  of  subplans  cannot  interact,  and  the 
notion  of  policy  will  be  meaningless.  The  second  requirement  is  related  to 
our  desire  for  flexibility.  New  knowledge  is  worthless  unless  it  is  expressed 
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in  a familiar  language.  There  should  be  jusf  one  obvious  wag  to  express  any 
given  piece  of  control  information.  (Keep  this  in  mind  as  I expand  on  the  set 
of  control  concepts  in  the  following  sections.) 

An  example  of  a good  limitation  is  that  no  loops  and  conditionals  are 
allowed  in  the  language.  That  is,  all  iteration  and  testing  is  done  in  the 
deducer.  There  are  no  gotos  in  the  system.  There  are  instead  much  higher- 
level  concepts  like  "choosing."  It  remains  to  be  seen  whether  I have  been 
successful  in  inventing  transparent  but  powerful  control  ideas.  (I  should 
mention  that  recursion  is  not  forbidden  in  the  system;  a plan-schema  instance 
can  have  subtasks  derived  from  an  instance  of  the  same  schema.  It  probably 
should  be  forbidden,  in  this  general  form;  I use  it  sparingly.) 

II.B  Interpretation  and  Inference 

One  thing  to  do  with  the  predicates  I introduced  in  the  last  section  is  to 
put  them  in  axioms  and  prove  things  with  them.  For  example,  many  of  the 
electronics  and  design  facts  in  Appendices  2 and  3 have  conclusions  of  the 
form  t/:TASK  ,..),  meaning,  "I  should  be  doing  ...."  Clearly,  a system  which 
just  proved  things  of  this  sort  without  acting  on  them  would  be  a perfect 
catatonic.  Its  deductions  would  occur  in  a void.  Their  full  meaning  depends 
on  there  being  an  "action  system"  which  interprets  the  result  of  such 
deductions  as  commands  to  act.  I will  call  formulas  like  this  which  directly 
influence  action  pragmatic  rormu1as\  the  characteristic  functions  of  these 
formulas  are  pragmatic  functions  or,  more  specifically,  pragmatic  predicates. 

I have  already  observed  the  convention  that  the  names  of  such  functions  and 
predicates  always  start  with  to  emphasize  that  their  meanings  depend 

nnstly  on  the  action  system.  In  this  section  I will  introduce  more  of  them. 
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(A  complete  catalog  appears  in  Appendix  1.)  All  predicates  not  directly 
Influencing  action  mean,  in  some  sense,  only  uhat  the  axioms  they  appear  in 
say  they  mean. 

In  this  section  I describe  the  operation  of  the  interpreter  and  the 
theorem  proven  it  uses,  called  STP. 

II.B.l  The  NASL  Interpreter 

The  outer  loop  of  the  interpreter  is  to 

Pick  a task  to  work  on; 

If  it  i s pr i m i t i ve. 

Execute  it  or  elaborate  it; 

Otherwise,  find  a way  to  work  on  it  ("reduce”  it); 

Repeat  until  there  are  no  more  tasks 

The  first  step  of  the  interpreter  cycle,  "picking  a task,"  is  done  by  a 
system  of  forward  deduction  of  /iSUCCESSOR  relations.  The  axioms  that  support 
these  deductions  are  the  user’s  responsibility.  The  system  chooses  at  random 
from  the  tasks  that  it  is  logically  permitted  to  do  next. 

Much  of  the  work  is  in  the  second  arm  of  the  conditional.  The  existence 
of  this  step  is  what  makes  NASL  a problem-reduction  problem  solver  instead  of 
a progr amm i ng- 1 anguage  interpreter.  Reducing  a task  involves  a call  to  the 
theorem  prover  STP  and  some  more  powerful  mechanisms.  (Sect.  II. Cl 

1 1. B. 1.1  Selecting  a Task  to  Uork  On 

The  NASL  interpreter  interleaves  planning  and  execution  of  plans.  (Cf. 
(Nilsson,  1973).)  Different  tasks  are  in  different  states,  which  change  as 
time  passes.  The  current  state  of  a task  is  composed  of  its  task-status,  its 
anablamant  status,  and,  for  problematic  tasks,  whether  it  is  reduced.  (Fig. 

I 
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1 1.  A)  Uhen  a task  is  created,  its  state  is  PENDING  and  BLOCKED.  When  a 
pending  task  is  ready  to  be  executed,  it  becomes  ENABLED.  Uhile  it  is  being 
worked  on,  it  is  ACTIVE.  Uhen  the  interpreter  is  through  with  it,  it  is 
FINISHED.  The  status  of  a task  is  expressed  in  a formula  of  the  form 
[«/>  ’ (/: TASK-STATUS  | task  name|)  |status|l 
where  status  is  one  of  the  three  states  I gave. 


PENDING 

ACTIVE 

FINISHED 

BLOCKED 

ENABLED 

SUBS-ENABLED 

SUCCS-ENABLED 

un- REDUCED 


REDUCED 


time 


Figure  II. A Life  History  of  a Task 

Meanwhile,  as  a task  evolves,  its  enablement  status  changes  to  "gate"  its 
subtasks  and  successor  tasks.  Recall  from  Sect.  1 1.  A that  the  order  of 
execution  of  tasks  is  constrained  by  /:SUCCES50R  relations.  In  addition, 
subtasks  of  a task  may  be  deduced  before  the  task  itself  becomes  active;  the 
subtasks  must  be  postponed.  So  there  are  three  facts  that  must  he  true  before 
a task  can  be  enabled:  all  its  super-tasks  must  be  ACTIVE;  all  of  its  input 
pvars  must  be  known;  and  all  of  its  predecessors  must  have  enablement  status 
"successors  enabled."  (Fig.  II. A)  Uhen  a task  is  FINISHED,  its  successors 
are  always  enabled,  but  the  system  must  be  flexible  enough  to  allow  execution 
of  successors  to  begin  before  this.  For  this  reason,  I introduce  the 
independent  concept  of  enablement  status, 

(-/>  ' l/rENAR-STATUS  |task  name|l  |status|l, 
where  status  is  BLOCKED,  ENABLED,  SUBS-ENADLED,  or  SlICCS-ENABl  ED.  These  flags 
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are  synchronized  with  the  ordinary  task'Status  as  shown  in  Fig.  II. A.  As  a 
task  becomes  active,  the  system  checks  its  subtasks,  and  enables  all  ttiose 
with  no  other  impediments;  similarly,  when  the  task  enters  5UCCS-ENAPLED  mode, 
the  system  checks  its  successors.  (It  should  be  clear  that  if  a task  has  two 
predecessors  or  super-tasks  or  some  combination,  all  must  be  in  the  proper 
state. ) 

A useful  service  provided  by  the  system  is  that  as  soon  as  all  the  input 
pvars  of  a task  are  known,  whether  or  not  there  are  other  gating  conditions 
remaining  unsatisfied,  a formula  of  the  form 

(/: TASK-ACTION  | task  name|  |action|l 
is  recorded  in  the  data  base. 

Figure  11.4  also  shows  the  transition  of  a problematic  task  from  being 
"unreduced"  to  being  "reduced."  Uhen  a task  has  been  completely  replaced  by 
subtasks,  the  proposition 

I/: REDUCED  |task  name|l 

is  supposed  to  hold  true  of  it.  The  system  will  not  bother  to  reduce  a task 
if  such  a formula  has  already  been  deduced;  this  enables  task  networks  to  he 
built  up  entirely  by  forward  deduction. 

II. B. 1.2  Executing  Tasks 

Uhen  a task  has  been  selected,  it  must  be  executed.  If  its  action  is  of 
the  form  (|r|  ...1,  I call  f its  action  function.  The  system  can  tell  by 
looking  in  the  data  base  or  on  the  property  list  of  f whether  the  task  is 
primitive  or  problematic.  If  it  is  problematic,  it  must  be  reduced. 
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II. B. 1.2.1  Primitive  and  Problematic  Tasks 

An  action  can  be  primitive  in  one  of  two  ways:  its  action  function  can 
have  a defining  LISP  function  on  its  property  list,  or  it  can  be  defined  by 
mode  I -man  i pu I at i on  axioms.  The  latter  are  looked  for  first. 

The  interpreter  calls  STP  to  deduce  formulas  of  the  form 

[/:f10D-nANIP  Mask  name!  |action|  70ELETELIST  7ADDLIST), 
where  the  variables  7DELETELIST  and  7A00LIST  are  intended  to  become  bound  to 
tuples  of  "senses,"  or  quoted  facts.  (See  Appendix  1.)  For  example,  we  might 
have 

((ON  7X  7BI  D 

(/:nOO-MANIP  7TASK  (HOVE  7X  7A)  <’ (ON  7K  7B)>  <’ (ON  7X  7A)>)1 
in  the  BLOCKS  world.  The  meanings  of  the  addlist  and  deletelist  are  the 
traditional  ones.  (Fikes  and  Nilsson,  1971)  The  model  (data  pool)  is  to  be 
updated  in  the  obvious  way:  the  formulas  represented  by  the  elements  of  the 
deletelist  are  deleted,  and  those  represented  by  the  addlist  are  adc)ed.  These 
manipulations  are  called  model  effects. 

If  the  primitive  has  a defining  LISP  f unc  t i on  on  its  proper  t y list,  that 
function  will  just  be  executed.  It  can  do  something,  return  a value, 
establish  a policy,  or  annex  a subnet.  An  example  of  the  first  kind  is  the 
action  (GRA6BA  (property|J  in  the  design  world,  which  creates  an  object  with 
the  property.  Values  are  returned  by  deductive  actions  like  /:FINn,  which 
call  STP  to  retrieve  data. 

The  most  important  kind  of  primitive  is  the  "macro,"  which  annexes  a 
subnet.  The  typical  member  of  this  class  is 

(/:(DO-SUflNET  |plan  schema|  |vars-map|l. 


which  is  used  to  instantiate  plan  schemata  and  hang  them  off  the  net. 
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In  the  current  implementation  of  NASL,  plan  schemata  are  not  represented 
as  identifiable  objects.  Instead,  they  are  defined  implicitly  through 
statements  of  the  form 

((/: PLAN- INSTANCE  ’NAPE  |plan  schema!  7SUPER-TASK) 

D (AND  (/:TA5K  j subtask  Ij  ...) 

l/:TASIf  jsubtask  2|  ...) 

(/:SUBTA5lf  jsubtask  Ij  7SUPER-TASK) 

(/: SUCCESSOR  jsubtask  Ij  jsubtask  2j) 

-other  connectivity  relations-)] 

by  uhich  nets  of  subtasks  are  created  and  linked  together.  Executing  /:D0- 
SU6NET  creates  a new  plan  instance  and  records 

(/:PLAN-INSTANCE  jplan  instance  namej  jplan  schemaj  j super  taskj]. 

This  uill  trigger  the  forward  deduction  of  subtasks  in  the  schema. 

These  subtasks  will  compute  and  use  the  values  of  plan  variables 
("pvars"),  some  of  which  the  super-task  network  needs;  the  vars-map  argument 
of  /:DO-SUBNET  tells  how  to  map  the  schema’s  variable  back  to  the  calling 
plan.  To  make  this  work,  all  the  pvars  used  by  the  tasks  In  the  schema  must 
be  of  the  form  ((jvar  namej  jplan  instance  namej)).  (For  an  example  of  the 
use  of  /:DO-SUBNET,  see  the  formulas  fOESl-1  and  +DESI-2  in  Appendix  2.) 

A macro-expanded  task  will  be  FINISHED  when  all  its  eubtasks  are.  It  will 
have  enablement  status  SUCCS-ENABLED  when  all  of  its  "main"  sub*asks  are 
FINISHED.  This  device  is  intended  to  capture  the  idea  of  a task  reducing  to 
two  )^ind8  of  subproblem:  things  which  must  be  done  before  going  on  to  the 
successors  of  the  task,  and  things  which  can  wait.  An  example  is  biasing  one 
stage  of  a complex  circuit  (see  Appendix  3);  this  will  appear  as  a sutjtask  of 
acquiring  a circuit,  but  it  should  not  be  done  when  the  circuit  is  first 
obtained;  instead,  it  may  become  a successor  of,  e.g.,  coupling  the  circuit 
to  something  else.  Subtasks  labeled  /:NAIN  are  those  whose  completion  is  a 
necessary  condition  for  enabling  a supertask’s  successors.  (See  Fig.  II. S.) 
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Acquire  Stage  1 


AMAIN  O- 


/:MAIN  O 


O Couple  them 


Successor 

Implicit  successor  due 
to  task  being  labeled 
MAIN 


Bias  it 

o 


Figure  I 1. 5 Enablement  Relations  in  Subnets 

This  is  one  of  the  ways  in  which  the  subtask  relation  differs  from  the 
usual  relation  between  a program  step  and  its  program. 

Other  macro  actions  are  described  in  Appendix  1. 

This  concludes  my  description  of  the  execution  of  macros  and  other 
primitives.  All  other  tasks  have  "problematic"  actions.  In  such  a case,  NASL 
calls  STP  with  the  request 

I/:  TO-DO  I task  name|  |action|  < -output  vars-  > ?UAY) 

If  STP  returns  exactly  one  value  for  'i’UAY.  a new  task  for  the  new  action  is 
created,  enabled,  and  made  the  /ttlAIN  subtask  of  the  current  task  (which 
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becomes  /:RE0tJCED).  If  STP  does  not  return  exactly  one  value,  special  things 
must  occur  which  are  the  topic  of  Sect.  II.C. 

I I. B.  1.2.2  Primary  and  Secondary  Tasks 

Primary  tasks  are  those  which  do  something  or  infer  something.  Primitive 
primary  tasks  are  those  defined  by  /:nOO-HANIP  and  inferential  functions. 
Secondary  tasks  ("poJfcfes")  are  those  which  influence  the  execution  of 
primary  tasks. 

The  principal  primitive  policy  is 

l/tMONlTOR  |formula|  (X  (1^1)  |action|)l, 
which  does  nothing  unless  some  task  removes  the  formula  as  a model  effect. 
Then  a new  subtask  will  be  created  with  the  given  action,  with  v bounrl  to  the 
task  that  did  the  removal.  This  is  used  to  implement  protection. 

Policies  may  cause  the  "intermittent"  execution  of  primary  actions.  A 
task  with  action  I/:C0NT1NUE  Ipolicy  task|  |action|]  will  be  executed  in  a 
nonstandard  way.  It  causes  a deduction  of  the  form 

I/:  TO-CONT I NUE  Ipolicy  task|  |action|  <>  '^UAYI 
and  the  resulting  sub-action  is  attached  to  the  original  policy  task  node  of 
the  task  network.  (See  the  implementation  of  protection  described  in  Chapter 
III.)  Thus  a policy  may  occasionally  cause  execution  of  real  actions  in  the 
process  of  executing  /:CONTINUEs. 

A problematic  task  may  also  be  primary  or  secondary.  This  is  not 
determined  when  the  task  is  reduced,  but  after  its  /:MAIN  subtasks  tiave  been 
set  up.  At  that  time,  if  any  of  its  subtasks  are  discovered  to  be  secondary, 
and  to  have  a scope  larger  than  it,  it  is  declared  to  be  a policy. 

The  main  difference  between  the  execution  of  primary  and  secondary  tasks 
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is  in  how  they  are  finished.  A secondary  primitive  will  not  be  finisher!  until 
the  task  which  is  its  scope  is  finished;  then  the  interpreter  executes 
t/:FINlSH  |policy|l  to  clean  it  up.  Problematic  tasks  of  both  kinds  are 
finished  when  all  their  subtasks  are. 

Here  is  a summary  of  the  ways  in  which  policies  influence  primary  actions; 

(1)  The  primitive  policy  /rflONITOR  is  used  to  implement  things  like 
"protection.”  (Sussman,  1975) 

(2)  The  presence  of  formulas  regarding  the  status  of  a task  can  license 
deductions  of  various  sorts.  The  conclusions  can  be  of  the  form  [/:TASK  ...] 
and  (/:  TO-DO  ...),  for  example,  and  thus  trigger  things  to  do  and  ways  of 
doing  them. 

(3)  In  particular,  policies  often  influence  the  "choice  protocol" 
described  in  the  next  section. 

14)  The  use  of  /:CONTINUE  can  cause  intermittent  execution  of  primary 
act  ions. 

Uhen  policy-specifying  formulas  influence  the  interpreter’s  deductions,  it 
will  record  their  influence  in  the  form  of  /:SUBTASK  assertions.  That  is, 
when  /:TASK  formulas  are  deduced  from  policy  task  formulas,  they  become 
subtasks  of  those  policies.  (Sect.  II.O)  Thus,  a natural  structure  evolves 
in  which  a task  can  be  a subtask  of  "make  a filter"  (primary)  anti  "keep  the 
cost  down"  (secondary). 


II.B,2  STP  --  The  Stupid  Theorem  Prover 

STP  is  a backward-cha i n i ng,  pattern-matching  theorem  prover.  In  R. 
rioore’s  (1975)  phrase,  it  is  a procedural  deductive  system.  Such  a system  may 
besf  be  thought  of  as  a descendant  of  PLANNER  (Hewitt,  1972)  which  emphasires 
its  logical  aspects  instead  of  emphasizing  its  progr amm i ng- I anguage  features 
as  most  other  descendants  have  done.  By  this  I mean  that  it  man  i |iu  I a t es,  not 
arbitrary  list  structures,  but  formulas  that  are  supposed  to  represent 
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statements  about  entities.  1 het e are  no  side  effects  during  deduction;  the 
action  system  is  completely  divorced  from  the  operation  of  the  theorem  proven. 
This  means  that  the  theorem  proven  can  be  optimized  in  various  special  uays. 
(See  Appendix  A.) 

STP  is  used  by  the  system  for  twc  kinds  of  deductions:  those  about  tasks 

and  actioni.  and  those  about  the  physics  of  the  problem  domain. 

STP  is  not  particularly  bright:  it  is  to  be  used  for  information 
retrieval,  and  it  tends  to  balk  at  intricate  reasoning.  More  sophisticated 
reasoning  is  done  as  inferential  tasks.  (There  are  things  to  regret  atiout 
this  organization.  See  Sect.  VI. B.)  Some  kinds  of  reasoning  do  not  naturally 
fit  into  the  theorem-proving  paradigm  at  all.  These  uill  be  discussed  in 

Sec  t . I I . C. 

Actually,  "theorem  prover"  is  a very  misleading  term.  The  "theorems’  such 
programs  prove  would  not  be  recognizable  to  a mathematician;  tne  way  in  which 
they  go  about  it  would  be  even  more  incomprehensible.  Nonetheless,  I will 
continue  to  use  this  term,  since  by  now  AI  people  are  unlikely  to  read 
anything  very  pretentious  into  it. 

A theorem  prover  may  be  thought  of  as  a problem-oriented  interface  between 
a problem  solver  and  bare  data-base  machinery,  such  as  that  descriijed  in 
(McDermott,  1975).  For  example,  an  AI  data-base  manager  implements  ttie  notion 
of  "da*a  pool."  This  will  be  used  to  implement  the  higher-level  notions  of 
"packet"  and  "reference  point."  (See  below.)  The  calculations  involved  can  be 
made  invisible  to  the  user,  who  thinks  in  the  higher-level  terms. 

The  basic  data-base  operations  are  three:  putting  things  in,  taking  things 
out,  and  finding  things.  These  are  handled  by  the  three  primitive  (LISP) 
operations  RECDHO,  ERASE,  and  STP.  RECORD  puts  a formula  into  a data  pool.  * 
It  also  does  forward  deductions  from  that  formula  in  a way  to  be  described. 
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The  results  of  these  derJuctions  are  recorded  also,  and  conclusions  are  linked 
by  "data  dependencies"  to  the  formulas  which  support  them.  (See  Sect.  II.D.I 
ERASE  flushes  a formula  and  everything  it  supports  from  a data  pool. 

Uhen  proving  theorems,  STP  works,  like  every  other  "theorem  prover,"  by 
matching  goal  formulas  against  "knowledge"  formulas,  detaching  the  output,  and 
repeating  until  a proof  from  atomic  data  is  obtained.  (Cf.  (Bledsoe,  IT/S) 

For  technical  reasons  (R.  tloore,  1975),  STP  really  attempts  to  refute  the 
negations  of  goals.  See  Appendix  4.) 

Formulas  are  stored  in  the  data  base  in  clause  form.  Clauses  are 

implications  whose  format  tells  how  they  are  to  be  used.  The  two  most  common 

forms  are 

I 

(-/>  C IpI  (qIJ.  meaning,  "to  prove  g,  prove  p" 

and  [-/>  A |p|  |q|1,  mearing,  "if  p is  recorded,  record  g. " 

(These  correspond  in  an  obvious  way  to  Planner's  consequent  and  anteceilerit 

theorems.  (Hewitt,  1372,  tloore,  19751)  The  arguments  p and  q to  these 

predicates  can  be  clauses  as  well;  my  clauses  have  more  pragmatic  strurtute 

than  those  of  a resolution  theorem  proven.  (Robinson,  19B5) 

I Internally,  these  clauses  are  stored  as  (pragmatic)  disjunctions  of  the 

, form 

l/tCONSEQ  |q|  (NOT  |p|)l 
I and  I/:ANTEC  (NOT  |p|)  |q|] 

respectively.  These  forms  are  occasionally  useful  externally  as  well. 

A third  pragmatic  disjunction  is  /:GEN.  l/tGEN  |p|  |q|l,  when  "recorded," 

* really  causes  counterexamples  to  p to  be  found  and,  for  each  one  found,  an 

I Instance  of  q to  be  recorded.  This  may  be  also  be  expressed  [-/•>  G (NOT  lp|) 

|q|].  For  example,  recording 

(-/>  G (DEV-TYPE  ?X  COnnON-ENITTER) 

(DEV-TYPE  ?X  AnPLIFIERM 
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STP  is  oriented  toward  the  task  of  information  retrieval.  Uhen  given  a 
goal  with  free  variables,  it  doesn’t  interpret  i t as  a recpjest  to  prove  that 
objects  exist  which  would  satisfy  the  formula  If  substituted  In;  instead,  it 
considers  it  a request  to  find  and  return  these  objects.  This  is  like  PLANNER 
(Hewitt,  1972)  and  QA3  (Green,  1963a, b),  (See  Appendix  A.) 

For  example,  given  the  clauses 


(P  A) 

(P  01 

[Q  0] 

[-/>  C (AND  (P  ?X)  (Q  ?XI) 

(R  ?X)1 

and  the  goal:  Refute  (NOT  (R  ?Y)1, 

STP  chains  backward  through  the  consequent  clause  to  generate  as  subgoal 


Refute  (NOT  (AND  (P  ?Y)  (0  ?Y))1. 

This  becomes  two  "conjunctive  goals":  "Refute  (NOT  (P  ?Y)1"  and  "Refute  (NOT 
(Q  ?Y)1."  STP  finds  Y -*  A and  Y -♦  0 as  answers  to  the  first  goal,  and 
detaches  (NOT  (Q  All  and  (NOT  (Q  0)1  as  alternative  versions  of  the  second. 
Only  the  latter  of  these  succeeds.  The  returned  answer  is  therefore  Y -•  0. 

The  machinery  to  make  this  work  reasonably  well  is  described 
in  Appendix  A. 

Some  other  interesting  features  of  STP  are  these: 

(1)  Ability  to  call  LISP  functions  for  low-level  deductions.  (Cf. 

(Nevins,  197Aa,b).l  I have  made  an  effort  to  keep  all  such  LISP-implemented 
concepts  completely  primitive  and  domain- independent.  These  are  concepts  for 
manipulating  simple  inequalities,  predicates  on  embedded  formulas,  etc. 

(2)  "Non-monotonic"  inference  rules,  which  are  implemented  by  having 
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certain  predicates  be  evaluated  by  calling  STP  recursively.  For  example, 

1/ ! CONS  I STENTL  Y ’|pattern|l  ui  I I be  handled  by  calling  STP  to  see  if  pattern 
can  be  refuted.  (The  single  quote  is  used  to  flag  an  expression  uithin  uhich 
substitution  of  equals  for  equals  is  forbidden;  such  an  expression  is  called  a 
"sense.")  McCarthy's  "presumably"  operator  (McCarthy  and  Hayes,  1960)  is 
de f i ned  as 

[(PRESUMABLY  ' ?P  ?USE)  ■ (-/>  ?U5E  (/:C0NSISTENTLY  "?P)  ’P)) 
meaning,  "if  you  can't  prove  ?P  is  false,  assume  it's  true."  Thus  ue  have,  (VX 
(BIRO  ?X)  3 (PRESUMABLY  (CAN  ?X  FLY)  O),  uhich  means,  "If  X is  a bird,  then 
if  you  ever  need  to  check  if  he  can  fly,  assume  he  can  if  you  can't  prove  he 
can't."  (If  the  formula  had  had  "G"  instead  of  "C,"  the  attempt  to  refute  his 
ability  to  fly  would  be  done  at  the  time  he  was  detiuced  to  be  a bird.) 

(3)  Pragmatic  handling  of  equality.  The  usual  predicate-calculus  notion 
of  equality  does  not  correspond  very  closely  to  the  programming  notion  of 
evaluation.  If  you  ask  a theorem  prover,  "Find  ?x  such  that  2+2  • 7x,"  it 
will  tell  you,  "?x  « 2+2,"  which  is  true  but  useless.  An  action  module 
communicating  with  a deductive  system  must  have  the  concept  of  "useful 
expression.  " In  the  midst  of  problem  solving,  some  data  structures  are 
inherently  more  oriented  toward  getting  on  with  things.  Consequently,  STP 
works  closely  with  an  evaluator  (see  Fig.  1.9),  which  applies  rewriting  rules 
found  in  the  model  to  expressions.  Ue  have  already  seen  these  rules  in  action 
implementing  pvars.  They  look  like  [•/>  ' (+  2 21  A).  The  "sense"  quote  is  a 
way  of  forbidding  applying  the  rules  to  subexpressions.  (Otherwise,  the  rule 
would  rewrite  itself  as  (•/>  A A) . ) 

The  evaluator  is  used  by  the  interpreter,  by  user  plans  which  use  the 
/jEVAL  P‘  imitive,  and  by  STP.  (See  Appendices  A and  S.)  Normal  equality, 
f“  1*1  ly|J.  is  used  to  express  goals  like,  "prove  two  things  are  equal." 
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There  is  a "cheap"  equality  predicate  called  The  only  knowledge  about 

it  is  (:-  7THING  7THING1.  It  is  used  in  conjunctive  subgoals  to  "set" 
variables  for  future  use.  That  is,  the  goal  h-  7K  (FOO  BAR))  succeerls, 
setting  7X  to  IFOO  BAR).  The  system  will  not  waste  its  time  trying  to  prove  a 
goal  like  this  if  it  doesn’t  succeed  immediately. 

Uhen  an  equality  is  recorded  in  the  course  of  trying  to  prove  x and  y 
unequal,  the  system  makes  an  effort  to  translate  ii  into  a rewriting  rule; 
otherwise,  it  will  never  interact  with  other  deductions.  Cf.  (Bledsoe  and 
Tyson,  1975). 

(A)  "Packets."  It  often  inconvenient  to  have  to  record  a large 
conjunction  as  a consequence  of  some  forward  deduction.  For  example.  In 
electronics,  devices  are  of  various  types.  If  it  is  recorded  that  IDEV-IYPE 
0EV#73  COMMON-Eni  TTER)  , this  might  trigger  the  recording  ivla  "-/>  A")  of 
scores  of  facts  about  DEV/)73.  most  of  which  will  never  be  looked  at.  This  can 
be  avoided  by  writing  the  relevant  antecedent  implication  as 

[-/>  A (DEV-TYPE  7CE  COnflON-EMI TTER) 

(/:PKT  CE-PKT  (7CE) 

|fact  1| 

I fact  2 1 

I fact  n| ) 1 . 

As  explained  in  (fIcOermott,  1975),  defining  this  formula  will  create  a packet 
which  plays  the  role  of  the  large  conjunction  with  one  free  variable  '^/TtfCE. 

It  is  actually  implemented  as  a "data  pool  layer"  which  can  be  added  cheaply 
to  the  current  data  pool.  The  individual  facts  will  be  closed  and  Indexed 
only  as  they  are  accessed. 

(5)  A "modal"  notation  and  inference  mechanism.  A general  deductive 
system  should  be  able  to  reason  about  hypothetical  situations,  other  times, 
other  creatures'  beliefs,  etc.  These  concepts  are  in  the  domain  of  "modal" 


II  Expressing  (fnouleclge  in  NA5L 


70 


logic  (Hughes  and  Cressuell,  1972),  a difficult  study  with  many  problems.  I 
have  implemented  a modest  system  for  doing  some  very  simple  modal  deductions, 
which  uses  the  "data  pool"  mechanism  to  implement  "reference  points." 

(Montague,  1974,  Rescher  and  Urquhart,  1971) 

The  basic  modal  notation  in  the  NASL  language  is  IT  Ireference  point  | 
|term|),  which  stands  for  the  value  of  the  term  with  respect  to  the  given 
reference  point.  In  principle,  these  reference  points  could  be  other 
creatures’  minds,  arbitrary  points  in  time,  or  just  "possible  worlds."  Unrler 
this  last  i n t er  pr  e t a t i on,  logical  necessity  might  be  taken  to  mean  IVR  (T  ?R 
...)1,  or  "...  is  true  in  all  possible  worlds."  However,  this  would  require 
quantifying  over  reference  points,  a capability  I have  not  had  the  time  to 
pursue.  Instead,  DESI  confines  itself  to  the  use  of  constant  reference 
points.  These  are  used  (see  Chapter  IV)  for  things  like  the  DC  and 
B i nuso  i da  I -s t eady- s t a t e models  of  an  electronic  circuit. 

This  sort  of  mechanism  is  just  a convenient  notation  for  data  pools  (i.e., 
"contexts")  from  within  the  logical  language.  To  make  it  work,  I have 
introduced  some  notation  for  "frame"  axioms.  (Hayes,  1973a)  A reference  point 
Is  often  defined  in  terms  of  the  differences  between  itself  and  some  set  of 
super  reference  points  from  which  it  inherits  most  of  its  contents.  These 
definitions  are  written  thus: 

(FRAME  (reference  point | < -reference  points-  >)  means  that  a statement  is 
to  be  assumed  true  in  the  given  reference  point  if  it  is  true  in  one  of  the 
other  reference  points  and  cannot  be  proved  false.  The  given  reference  points 
are  called  frames  of  the  new  one.  That  is, 

((FRAME  7REF  ’FRAME-RErS)  - 
(Vf’  (3F  (?F  ( ?FRAnE-REFS)  /\  (T  ?F  ?P)) 

D (PRESUMABLY  ’(T  ?R  P)  0)1, 

Of  course,  it  isn’t  implemented  in  this  way.  Instead,  a new  data  pool  is 
constructed  using  the  FRAME  axioms  when  it  is  required.  This  data  pool  has  as 
superiors  the  data  pools  corresponding  to  its  frames. 
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IN  Ireference  pointj  ’|fact|)  means  that  the  given  fact  is  not  iniierited 
from  the  reference  point’s  frames. 

Formulas  of  the  form  IT  [reference  pointj  jfactj)  are  used  in  constructing 
new  reference  points.  Ang  such  propositions  lying  around  have  their  facts 
shoved  into  the  new  data  pool. 

Examples  of  the  use  of  these  formulas  are  given  in  Chapter  IV. 

II.C  Choice  and  Rephrasing 

As  sketched  so  far,  NASL  resembles  some  more  familiar  problem  solvers. 
Except  for  the  imposed  distinction  between  deduction  and  action,  it  is  a lot 
like  PLANNER.  (Hewitt,  1972)  The  main  difference  is  that  it  does  no 
backtracking  past  model  manipulations.  Since  it  is  more  disciplined  in  many 
ways,  it  is  better  able  to  explain  its  actions. 

However,  it  suffers  from  some  of  the  same  problems  as  PLANNER-1  ike 
systems.  In  particular,  a certain  amount  of  the  additivity  I wanted  will  not 
be  found  in  this  organization.  Even  though  it  is  easy  to  add  a new  plan 
schema  to  a body  of  facts,  the  interactions  of  this  new  material  with  the  old 
are  not  so  easily  handled. 

For  example,  if  acquiring  a common-collector  amplifier  is  known  to  be  a 
good  way  of  achieving  high  input  impedance,  this  fact  might  be  lying  around  in 
a formula  of  the  form 

("high  input  impedance  required" 

D (/!  TO-DO  ?T  (MAKE  AflPLIFlER)  <?N> 

(MAKE  COnnON-COLLECTORm. 

(For  a precise  version  of  this,  see  Appendix  3.)  Now,  say  that  the  system  is 
to  be  told  about  field-effect  transistors  (FETs).  Since  they  have  a high 
input  impedance,  an  exactly  similar  fact  will  be  recorded  regarding  the  FET 
common- source  amplifier. 
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Nou  a request  to  make  an  amplifier  Mill  cause  holh  these  fatts  to  tie 
retrieved.  Uhat  can  be  done?  (Ue  have  already  ruled  out  just  trying  one 
until  it  fails.)  One  approach  Mould  be  to  force  the  user  to  revise  one  or 
both  of  the  formulas  to  check  for  information  that  Mill  distinguish  ijetween 
the  tMo  cases.  Houever,  this  Mill  lead  to  large,  impenetrable  implications. 
Furthermore,  in  some  cases  of  such  confusion,  neither  choice  is  preferrerl,  but 
some  synthesis  of  the  tuo.  Ue  need  a May  to  represent  such  "di  f fer  ent  iai 
diagnosis"  and  "par t i al -so I ut i on  composition"  knouledge  in  an  arlditive  manner. 

The  solution  is  to  face  up  to  the  necessity  for  treating  "choice  hetueen 
alternatives"  as  a basic  situation  of  problem  solving,  and  to  create  neu 
pragmatic  predicates  for  handling  it.  This  is  the  subject  of  Sect.  ll.C.l. 

The  comp  I emen  tar  y problem  that  this  brings  to  mind  is  Mhen  the  rJerluc  t i ve 
pattern-based  backuard  chaining  of  STP  is  unable  to  retrieve  any  possible 
plans.  This  might  be  because  there  aren’t  any,  and  the  user  must  provide  new 
information,  but  it  also  might  be  because  the  relevant  retrieval  strategy 
depends  upon  pattern-manipulation  operations  which  are  less  disciplined  than 
unification.  For  example,  ue  might  want  to  express,  "If  the  problem  mentions 
HHz,  try  special  high-frequency  heuristics."  Here  the  traditional  Al  language 
solution  is  to  allow  arbitrary  list-processing  operations  upon  formulas.  (The 
traditional  predicate-calculus  solution  is  to  do  aimless  equality 
substitution.)  Thus,  in  CONNIVER  (McDermott  and  Sussman,  1973)  a method  with 
pattern  (LAMBDA  • >X  i>Y)  can  match  the  calling  pattern  (LAMBDA  (X)  (F  (G  X))) 
and  do  anything  it  likes  with  the  pieces  so  generated.  This  is  somewhat 
abhorrent,  since  it  tenrls  to  destroy  the  notion  that  formulas  mean  ar.  ug. 

Uho  can  rule  on  the  consistency  o<  a set  of  formulas  that  do  things  like  that? 

My  ap  )r  oach  to  this  problem  is  to  try  to  impose  some  disci(>line  on  ttiis 
kind  of  manipulation.  The  idea  is  to  signal  explicitly  when  the  system  is 
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a II  ou i ng  itself  to  do  things  like  that,  and  to  impose  restrictions  on  its 
behavior  and  the  results  it  computes.  This  idea  is  developed  into  the 
"rephrasing"  protocol  of  Sect.  II. C. 2. 

II.C.l  The  Choice  Protocol 

Under  some  circumstances,  STP  is  asked  to  return  all  the  answers  if  can 
find  (cf.  Appendix  4),  but  it  can  be  asked  to  return  just  one.  In  this 
situation,  if  more  than  one  answer  is  found,  the  sgstem  performs  a ritual 
invocation  of  information  about  choosing  between  them.  This  is  called  the 
choice  protocol.  For  example,  this  protocol  is  called  when  DESI  finds  more 
than  one  possible  circuit  for  a general  concept  like  "amplifier."  In  that 
case,  detailed  information  about  the  various  types  of  amplifier  interacts  with 
information  about  what  is  required  of  this  amplifier  to  force  a choice. 

The  first  thing  the  chooser  does  is  to  create  an  (abstract)  choice 
situation  name  and  record  in  the  data  pool 

I/:CH0ICE  |name|  |context|  [goal  formulal) 

(The  context  is  the  inferential  task  for  which  more  than  one  answer  is  found. 
In  the  case  of  the  interpreter  trying  to  deduce  how  to  do  something,  this  is 
just  the  symbol  "EXEC.")  For  example,  in  trying  to  choose  an  amplifier,  it 
would  record 

[/:CH0ICE  C«S35  EXEC 

[/:  TO-DO  TSX«437  (MAKE  AMPLIFIER)  <’ (STAGE  1 CI(T<f747)> 

?UAY) ) 

The  formal  resemblance  of  this  to  /:TASK  formulas  is  suggestive;  we  )iave  in 


effect  added  a new  kind  of  entity,  the  choice.  The  intent  is  that  this 
formula  will  trigger  forward  deductions  of  the  kinds  to  be  described  In  a 
moment.  The  packet  machinery  of  (flcOermott,  1975)  will  allow  the  system  to 
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bring  in  large  packets  of  what  mag  loosely  be  called  "advice"  appro(iriate  to 
this  situation. 

The  use  of  "brackets  inside  brackets"  is  our  first  encounter  with  the 
concept  of  "embedded  formula."  (See  Appendix  1).  The  system  is  treating  the 
goal  here  as  a dat"*  structure  to  be  analyzed. 

For  each  of  the  'Possible  answers,  a formula  of  the  form 

I/rOPTION  Ichoice  namej  |option  name)  |answer  formula|) 
is  recorded  in  the  data  pool.  For  our  amplifier  example,  we  might  have 

{/.•OPTION  C/T535  A<f450 

l/:T0-D0  TSK«437  (MAKE  AI1PLIFIER1  (STAGE  1 CKT«747)> 

(HAKE  COnnON-COLLECTORIll 

[/:OPTION  DT535  A«4S1 

[/:T0-D0  TSKA437  (HAKE  AnPLIFIER)  <' (5TAGE1  CKT«747)> 

(NAICE  FET-COnnON-SOURCEin 

Recording  these  formulas  will  trigger  the  de'luctlon  of  formulas  of  the 

form 

(/:RULE-OUT  |option  name|I  . 

(/:RULE-IN  | opt  ion  name|l, 

or  [/;RULE-TOGETHER  < -option  names-  > |new  answer  formula|l. 

The  system  first  searches  for  conclusions  of  the  form  (/:RULE-OUT  ...I. 
This  is  a call  to  STP,  of  course.  If  any  are  found,  the  options  ruled  out  are 
removed  from  consideration.  Next,  the  system  looks  for  conclusions  of  the 
form  (/:RLIl.E-IN  ...I,  If  any  of  these  are  found,  the  system  throws  away  all 
options  except  those  mentioned.  Finally,  it  looks  for  /:RULE-TOGETHERs.  If 
one  of  these  occurs,  the  options  it  mentions  are  discarded  in  favor  of  the  new 
answer  formula. 

If  at  any  stage  all  options  but  one  are  eliminated,  the  protocol  stops 


with  a winner.  If  all  the  options  are  ruled  out,  the  system  enters  an  error 
protocol  to  show  the  user  what  it  did  and  ask  for  corrections  of  its 
misinformation.  If  more  than  one  option  survives,  the  system  records 
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(/•.QUIESCENCE  (choice  name|l 
in  an  effort  to  trigger  more  forward  deductions. 

The  intent  of  these  devices  is  clear.  Differential  diagnosis  is  Sc  t)e 
performed  hy  the  first  two  kinds  of  formula,  while  / : Rl  H r-TOnC  THf  Rs  are 
intended  to  be  one  locus  of  composition  of  partial  solutions  in  the  NASL 
system.  (The  others  are  problem  reduction  (see  above)  and  error  correction 
(see  Sect.  III.D)  in  the  context  of  patching  electronic  circuits.)  The 
/tQUIESCENCE  trick  enables  the  user  to  encode  advice  of  the  form,  "All  ottier 
things  being  equal...,"  as  a forward  implication  like 

(-/>  A (/:QUIESCENCE  ?C)  ...). 

The  choice  protocol  keeps  track  of  the  rules  which  contribute  to  weeding 
out  all  but  one  option.  These  rules  are  used  in  building  data  dependencies 
(sect.  I 1.0).  In  addition,  when  a policy  is  used  in  choosing  a way  to  do 
something,  the  choice  is  made  a subtask  of  that  policy.  For  example,  say 
there  is  a policy  of  the  form  "keep  costs  low,"  plus  a deductive  rule  like, 

"Uhen  trying  to  make  a device,  and  trying  to  keep  costs  low,  then,  al  I 
other  things  being  equal,  if  a circuit  with  inductors  Is  competing  as  an 
option  against  a circuit  without  them,  the  one  with  inductors  is  ruled 
out.  " 

Now  if  the  task  of  constructing  some  circuit  is  elaborated  into  a device 
chosen  on  the  basis  of  this  rule,  the  task  of  acquiring  the  device  is  subtasK 
of  both  the  construction  task  and  the  costs  policy.  This  leads  to  clear 
explanations  by  the  system  of  its  behavior.  (Sect.  V.A) 

(The  choice  protocol  was  Inspired  by  the  design  of  flarcus’s  (1973,  1975) 
"wait-and-see"  parser,  which  does  similar  things  in  choosing  directions  in 
which  to  parse. ) 
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1 1 . C. 2 Rephras i ng 

I now  turn  to  one  of  the  most  important  and  least  elegant  subsgstems  ot 
NA5L , the  rephrasing  protocol . This  is  the  system  which  is  invoked  when  SIP 
is  unable  to  find  a reduction  of  a task.  Rephrasing  consists  in  treating  ttie 
recalcitrant  problem  as  an  object  to  be  transformed  into  a new  problem.  The 
pious  hope  is  that  the  new  one  is  easier.  This,  of  course,  is  precisely  the 
object  of  task  reduction  in  the  first  place.  So  rephrasing  may  be  thought  of 
as  taking  extraordinary  measures  to  reduce  a task. 

The  way  this  works  is  as  follows.  Uhen  the  system  is  unable  to  find  a way 
/; TO-DO  something,  a task 

(/ : TASK  I name | <> 

(X  ()  t/sREPHRASE  |task|  |action  formula!  < -output  pvars-  >))  <>) 
is  created,  and  made  a predecessor  of  the  losing  task.  This  task  is  allowed 
to  carry  out  arbitrary  inferences  in  order  to  reduce  the  unreduceable  task. 

For  example,  the  design  task  DESW78,  with  action 

(DESIGN  (X  (X)  (AND  (IS  AMPLIFIER  ?X) 

(-  (VOLTAGE-GAIN  ?X)  100)1  )) 

is  unlikely  to  trigger  an  indexed  solution.  Instead,  it  must  be  rephrased  as 
some  set  of  simpler  actions,  by  the  use  of  electronics  knowledge.  So  the  task 

I/s  TASK  T<f8A9  <> 

(X  0 (/! REPHRASE  DEStf78 

(DESIGN  (X  (X)  (AND  (IS  AMPLIFIER  ?X) 

(-  (VOLTAGE-GAIN  ?X)  100)1  )) 

< I resu I t pvar  j >)  ) 

<>1 

will  be  put  in  the  task  network  as  a predecessor  of  the  design  task.  Its 
effect  will  be  to  rerluce  task  DES<f78. 

The  rephrasing  protocol  must  exist  in  orrler  to  [srovide  for  deductions 
beyond  the  scope  of  STP’s  simple  strategies.  These  fall  into  two  categories. 
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one  more  elegont  thon  the  other.  First,  because  it  uses  the  interpreter,  it 
can  take  advantage  ot  the  choice  protocol,  flexible  planning  and  policg 
making,  and  even  recursive  rephrasing.  Thus,  for  example,  one  can  make  finer 
choices  than  is  allowed  bg  just  running  the  chooser  on  a set  of  possible 
reduc  t i ons. 

Second,  and  less  happily,  the  rephrasing  protocol  manipulates  the  action 
formula  as  an  "embedded  formula,"  and  so  is  allowed  to  perform  any  operation 
on  its  representation.  So  one  can  write  rephrasing  plans  which  check  to  see 
if  the  given  action  refers  to  "UIDGETS"  anywhere.  In  the  next  chapter.  I will 
show  how,  in  the  course  of  rephrasing  design  problems,  X -expressions  are 
routinely  dismembered.  This  seems  to  be  indispensable,  but  it  would  be  nice 
if  we  could  insist  that  the  pieces  be  put  back  together  in  a legitimate  way. 

This  is  a special  case  of  the  more  general  problem  of  making  sure  thaf  the 
interpreter  and  inference  mechanisms  actually  do  what  they  are  supposed  to  do. 
The  difficulty  is  in  specifying  what  the  object  of  a task  or  protocol  is.  For 
choice,  the  object  is  fairly  clear:  eliminate  all  but  one  option.  (Iiielegancy 
creeps  in  with  /:RLILE-TOGETHERS. ) Elsewhere  in  the  interpreter,  I have 
ignored  this  very  important  problem,  except  for  token  checks  such  as  that 
/tFINISH  actually  leave  its  task  finished.  In  the  case  of  rephrasing,  the 
problem  is  especially  acute;  rephrasing  can  be  thought  of  as  a device  for 
extending  the  pattern  matcher  by  allowing  arbitrary  deductions  about  formulas. 
Something  like  this  is  necessary,  but  it  should  be  better  constrained. 

As  it  is,  there  are  only  a few  restrictions  on  the  use  of  rephrasing:  all 

the  actions  undertaken  as  subtasks  of  a rephrasing  must  be  inferential,  not 
worldly;  the  rephrasing  task  must  leave  its  target  task  /:REDUrEri:  and  the 

subtasks  resulting  from  a rephrasing  must  be  syntactically  legal  (i,e.,  not 
contain  X's  in  funny  positions  or  have  any  free  variables,  etc.). 
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Thf-  rephrasing  knowledge  for  the  design  domain,  whicti  I present  in  ttie 
next  chapter,  is  an  example  of  what  rephrasing  oiic)ht  to  he.  The  formulas 
involved  are  reduced  to  pieces  by  one  task,  and  parser!  together  again  by 
others.  I hope  that  this  will  prove  to  be  an  instance  of  some  more  general 
recognition  strategy  that  is  more  constrained  than  what  the  system  now  allows. 

1 have  now  described  every  module  in  Fig.  1.9.  The  search  paradicjm  th.at  1 
have  developed  may  be  summarized  as:  let  the  theorem  prover  search,  but  not 

too  far  or  too  deeply.  All  searches  are  intended  to  be  short  and  sweet;  the 
search  is  used  for  exactly  those  spots  where  there  is  no  applicable  knowlerige. 
These  short  searches  are  organized  by  a plan  interpreter,  which  decides  what 
sort  of  knowledge  is  to  he  accessed.  It  can  ask  for  answers  to  riuestions 
about  how  to  do  things,  the  physics  of  the  domain,  choosing  among 
alternatives,  or  transforming  its  own  problem  statements.  Thus,  as  far  as  the 
paradigm  has  been  developed,  it  is  in  accordance  with  R.  Hoore’s  (1975) 
observation  that  theorem  provers  are  most  naturally  applicable  to  information 
retrieval  problems,  and  that  other  control  structures  are  neerled  for  more 
sophisticated  tasks. 

II.D  Dependencies  Among  Data  and  Tasks 

It  is  becoming  generally  realized  that  Al  systems  must  record  their 
reasons  for  their  conclusions  and  actions.  (flcDermott,  197Aa,  Stallman  and 
Sussman,  197G,  Short  I if fe,  1975)  These  records  have  many  uses: 

(1)  They  can  be  used  to  explain  reasoning  anti  actions  to  a human  user. 

(2)  They  guide  the  system  in  untloing  faulty  deductions. 

(3)  They  are  a guide  to  correcting  the  effects  of  misguided  actions. 

(A)  They  can  be  userl  in  assigning  the  blame  to  incorrect  rules. 


w 


The  basic  relation  among  data  is  the  deductive  data  dependency. 
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(HcDermott,  1375)  Every  time  STP  or  RECORO  does  a deduction,  it  attaches  such 
a dependency  to  the  conclusion  and  the  premisses;  the  latter  become  the 
supporters  of  the  dependency,  the  former,  the  supportee.  (See  Appendix  A.) 
Uhen  the  system  does  an  ERASE,  all  the  supportees  of  the  erased  item  are 
erased  themselves  if  they  have  no  remaining  supporters. 

These  support  relations  are  accessible  to  the  problem  solver  as  a set  of 
LI SP- i mp I emented  predicates.  In  particular, 

[/iSUPPORT  < -formula  names-  > | formula  name|] 
is  supposed  to  be  true  when  the  indicated  dependency  holds. 

These  support  dependencies  are  also  created  by  the  inferential  action 
/:  INFER  (see  Appendix  1).  Other  inferential  tasks  call  STP  and  let  it  build 
dependenc i es. 

These  devices  account  for  the  second  in  the  list  of  uses  of  dependencies 
among  data  and  tasks.  The  others  are  more  complicated,  because  they  involve 
the  relation  between  action  and  the  world  model.  Here  are  examples  of  the 
kinds  of  relations  that  can  occur: 

(1)  A task  can  have  model  effects.  The  relation  between  the  task  and  its 
effects  is  non-deduct i ve  because  erasing  a task  is  not  sufficient  to  undo  its 
effects.  (Besides,  some  of  the  effects  are  erasures.) 

(2)  A task  or  pvar  value  can  be  based  on  choice  information.  Ue  want  to 
record  this  relation,  but  erasing  the  basis  of  a choice  does  not  erase  the 
choice,  although  it  calls  the  wisdom  of  the  choice  into  question. 

(3)  Facts  in  the  current  model  can  support  task  statements.  A fact  ab'^ut 
circuit  topology  supports  a constraint  on  the  physical  quantities  it 
influences.  Erasing  sucii  a model-effect  formulas  should  cause  the  task 
formulas  to  he  erased  too, 

(A)  Facts  in  the  current  model  can  trigger  tasks.  This  is  a quite 
different  situation  from  (3).  NASL  implements  the  common  Al  mechanism  of 
"demon"  or  "pat  tern- tr i ggered  interrupt"  by  allowing  /:TA5K  and  /;SUBTASK 
formulas  to  be  deduced.  For  example,  a BLOCKS-worid  system  may  for  a time 
have  a policy  to  the  effect  that  a certain  block  BH72  is  to  have  a dear  top. 
This  gets  translated  into  the  principle. 
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IVX  (ON  ?X  B#72) 

D (3T  (/:TASK  ?T  <>  (X  0 (REflOVE  ?K  B«72))  <>))! 

Let  B#74  appear  on  BU72.  This  will  create  a task  to  take  it  off.  A model 
effect  of  this  task  is  the  erasure  of  (ON  B#74  Bff72)  and  with  it  the  task* 

This  contradicts  common  sense,  since  once  the  interpreter  starts  to  work  on 
something,  its  success  should  not  erase  it.  There  mag  even  he  serious  errors 
as  a result  of  such  an  erasure,  since  the  erased  task  mag  not  have  been 

completed  get.  In  ang  case,  the  user  mag  want  to  ask  questions  about  tasks, 

without  worrging  about  which  ones  erased  themselves. 

It  is  clear  that  this  problem  has  to  do  with  the  treatment  of  time.  An 
activitg  can  become  a task  for  one  reason,  but  stay  a task  for  another.  This 
is  handled  bg  the  use  of  the  modal  operator  S,  defined  as  follows:  (S  '|fact|l 

means  "fact  starts  to  be  true."  The  conclusion  of  the  given  implication 
should  be  (.  . . (S  (3T  (/:TASK  ?T...n)).  Exact  Ig  the  same  fact  will  end  up  in 
the  data  base,  but  the  supporting  data  dependencg  will  be  different.  (It  is  a 

bit  wishful  to  call  this  a "modal  operator"  instead  of  a "patch."  If  the 

modal  machinerg  were  better  developed,  it  could  be  supported  bg  axioms  like 

IT  ?R  ( (S  ’?P)  A ( (TIHE)  - ?tn 

3 (3i  (VQ  (T  ?Q  (?t  < (TiriE)  < ?t+?i) 

3 ?pmi. 


but  it  i sn’ t . ) 

To  represent  these  nuances,  the  structure  of  data-riependenc i es  must  be 

made  more  flexible.  Before,  the  supporters  list  of  a dependencg  was  just  a 

list  of  data;  now  we  make  it  a "labeled  tree"  of  tuples  of  data.  Each  label 

explains  the  role  the  supporters  plag  in  the  dependencg.  For  example,  a 

BLOCKS-uorld  program  might  execute  the  task 

I/:TASK  (FIND-OUnP)  <> 

(X  ()  (:FIND  (X  (X)  (IS  PLACE  ?X)  ))  ) 

<’  (OUnP) >] 

in  order  to  find  a place  to  get  rid  of  a nuisance  block.  If  it  chooses  X - 
TABLE  because  of  a choice  principle  C,  the  result 

(-/>  ’ (DUnP)  TABLE) 

will  be  supported  with  the  two  labeled  depenflenc  i es: 

(DD-CHOICE  (IIS  PLACE  TABLED  (DO-CPRIN  (CD)  and 
(DO-INf  ERER  ( iriND-OUnP)  D 

where  DO-CHOICE,  DO-CPRIN,  and  DD-INFERER  label  the  roles  of  the  formulas  theg 
dominate  in  their  trees.  (I  am  being  a little  casual  about  the  format  of 
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these  structures;  when  they  are  attached  to  the  data,  pointers  to  the 
supporting  data  themselves  appear  in  place  of  their  formulas.) 

Here  are  some  of  the  implemented  labels: 

(DD-ACT-RESULT  ( | task  datum|) 

(DD-APRIN  -action  principles-) 

(DO-ATRIGGER  -action  triggers-)) 

relates  a task  to  its  results.  The  action  principles  are  general 
formulas  (found  in  the  main  data  pool  GENERAL-DP*);  the  action  triggers  are 
formulas  that  were  true  (perhaps  transiently)  when  the  action  occurred. 

Erasing  the  latter  will  not  disturb  the  supportee  of  the  data  dependency. 

(DD-CHOICE  (-inferential  supporters-) 

(DO-CPRIN  -choice  principles-) 

(DD-CTRIGGER  -choice  triggers-)) 

records  an  inference  for  which  an  answer  had  to  be  chosen.  The  rules 
which  contributed  to  this  selection  are  sorted  into  triggers  and  (jrlnciples 
just  the  way  they  are  for  actions,  but,  for  choices,  the  supportee  is  Immune 
j from  disturbances  to  either  of  the  kinds  of  choice  formula. 

(DO-S  (-triggers-)) 

labels  supporters  whose  erasure  does  not  affect  the  supportee. 

Deducing  (S  ’|r|)  will  record  (jri)  with  the  supporters  insulated  by  a 00-S 
I abe I . 

(DO-INFERER  (jtask  datum|)) 

is  attached  to  formulas  deduced  or  inferred  by  inferential  tasks.  This 
is  used  by  other  inferential  tasks  to  refer  to  those  formulas. 

(DD-ISTATE  (-data-)) 

! is  used  to  label  formulas,  like  /:TASK  formulas  and  pvar  value 

I assertions,  which  define  the  state  of  the  interpreter.  These  formulas  are 

"incorrigible,"  and  are  never  erased. 

i 

j (DO-EXEC  ( I task  datumj)  (-other  data-)) 

records  other  miscellaneous  relations  between  a task  and  a formula 

(DD-T  jdata  poolj  (-data-)) 

links  data  across  reference  points.  The  intent  is  to  record  ttiat  the 
■ presence  of  the  data  in  the  foreign  data  pool  are  responsible  for  the  presence 

> of  the  supportee  (which  may  be  a DO-T  itself). 

This  information  can  be  dumped  out  in  a revealing  form,  as  described  in 


Chapter  V. 
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II.E  Handling  Hi  stakes 

Consider  situations  like  the  follouing: 

You  are  dialing  a telephone  number.  Halfuay  through,  you  feel  your  hand 
slip  and  you  knou  you  have  misdialed. 

There  is  a pouer  failure.  You  wonder  if  the  refrigerator  will  be  damaged. 
You  flick  the  kitchen  light  switch  on  to  have  a closer  look.  Nothing  happens. 

Someone  asks  you  to  design  an  amplifier  with  a certain  high  gain-bandwidth 
product.  You  confidently  pick  a familiar  circuit  topology  and  begin  to 
compute  the  required  component  values.  You  discover  there  are  no  component 
values  that  will  do  the  trick. 

All  of  tfiese  are  examples  of  "mistakes."  (A  finer  classification  is  possible. 
Cf.  (Ni  Isson,  1973).)  They  all  have  in  common,  in  the  terms  I have  been 
developing,  that  the  plan  for  accomplishing  a certain  task  has  been  shown  not 
to  work.  In  each  case,  it  is  wholly  or  partly  useless  to  continue  on  the 
plotted  course. 

Not  enough  work  has  been  done  in  AI  on  correcting  such  mistakes.  (But  see 
Nilsson,  1973,  Philip  Hayes,  1975,  Sacerdoti,  1975.)  Instead,  we  have  spent  a 
lot  of  effort  on  seemingly  similar  search  problems  in  which  "blind  alleys"  are 
searched,  and  real  mistakes  never  occur.  I discussed  this  briefly  at  the 
beginning  of  this  chapter.  The  problem  with  even  the  most  sophisticated  of 
mechanisms  for  searching  through  blind  alleys  (Stallman  and  Sussman.  197B)  is 
that  they  rely  on  the  ability  to  restore  previous  choice  points.  Previous 
discussion  of  the  problems  associated  with  this  (e.g.,  McDermott  and  Sussman. 
1972)  has  focused  on  the  difficulty  in  choosing  a choice  point  to  restore: 
here  I wish  to  call  attention  to  the  impossibility  of  restoring  most  choice 
points  in  any  useful  way.  The  problem  is  that  the  range  of  choices  previously 
available  may  be  obsolete.  Sometimes  this  is  because  some  of  the  choices  have 
been  ruled  out  by  other  processes.  This  is  handled  nicely  by  Stallman  and 
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Sussman’ 3 EL  (197G).  A worse  problem  is  that  non-monotonic  inferences  made  at 
the  time  of  the  old  choice  may  have  been  rendered  incorrect  by  further 
discoveries  or  changes  since  the  old  choice.  (McDermott.  1974a)  For  example, 
the  range  of  choices  available  for  instantiating  an  amplifier  can  change 
dramatically  after  adjacent  stages  are  instantiated.  There  is  no  way  to 
return  to  one  choice  point  without  considering  all  the  choices  and  actions  in 
between. 

The  alternative  scheme  I am  about  to  outline  has  not  been  implemented, 
although  many  of  the  pieces  are  in  place. 

The  idea  is  to  treat  correcting  a mistake  as  a task  like  any  other.  The 
mistake  is  given  a description  by  the  primitive  that  failed.  (For  example,  if 
a constraint  cannot  be  satisfied,  the  mistake  is  described  as  (CONSTRAINT- 
COLLAPSE  (losing  constraint!).)  The  system  sets  itself  the  task 

(/:GET-RID-0F  (mistake  descr ipt i on( ] . 

Often  it  will  be  necessary  to  re-describe  the  situation;  this  is  a job  for  the 
rephrasing  protocol.  A typical  electronics-domain  redescription  might  be 

(IMPROVE  ’(GAIN  (STAGEA89) ) ) . 

Plans  are  retrieved  to  carry  this  out.  (Cf.  Chapter  I.) 

The  difference  between  this  and  and  a routine  situation  is  that  the  task 
network  must  be  corrected  in  some  way.  Some  of  the  tasks  that  existed  before 
the  mistake  are  still  "healthy,"  else  there  would  be  no  reason  to  go  on 
living,  but  some  of  the  subtasks  are  now  "rotten,"  and  may  be  replaced.  A 
Bubtask  of  a /:GET-RID-0F  task  is  allowed  to  alter  certain  parts  of  the  task 
network. 

Making  the  network-editing  machinery  work  is  the  hardest  part  of 
implementing  this  scheme.  The  kinds  of  edits  that  must  be  allowed  include 

> Adding  new  subtasks  to  correct  the  problem..  The  commonest  reaction  to 
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an  accidental  "protection  violation"  (Sussman,  1975)  is  to  re-es tat) I i sh  the 
protected  fact  without  further  fuss. 

> Restarting  old  suhtasks.  For  example,  the  string  of  tasks  involved  In 
dialing  the  first  digits  of  a misdialed  telephone  number  must  be  resurrected. 

> Detaching  and  redescribing  old  subtasks.  For  example,  introducing  too 
much  feedback  can  cause  oscillation;  its  old  description  (that  it  die) 
something  useful)  must  be  discarded,  and  it  must  be  seen  as  part  of  the 
problem  instead  of  part  of  the  solution.  Its  old  supertask  must  be  marked  un- 
/: REDUCED  again,  and  a new  way  must  be  found  to  solve  it. 

> Terminating  active  subtasks,  especially  policies,  of  a rotten  task.  In 
electronics,  constraints  derived  from  circuit  diagrams  must  be  removed  when  an 
IMPROVE  task  is  executed  and  changes  the  topology  of  the  circuit  diagram. 

The  information  about  what  edits  are  legal  must  be  part  of  the  mistake 
handler.  For  example,  the  plans  regarding  constraint  collapse  (see  Chapter 
III)  must  specify  that  the  highest  task  that  is  the  scope  of  some  of  the 
collapsed  constraints  is  still  healthy;  some  lower-level  task  (probably 
associated  with  a particular  canned  circuit  diagram)  must  be  declared  rotten 
and  its  policies  abandoned. 

The  reason  why  this  scheme  has  not  been  implemented  is  that  it  depends  on 
the  data-dependency  machinery  I described,  which  is  still  relatively  untested 
itsejf.  Undoubtedly  both  of  these  systems  will  grow  together. 


II.F  Programmer’s  Guide 


As  I said,  NASL  is  not  exactly  a programming  language,  but  it's  not  a 
natural  language  either,  so  it  is  probably  best  for  the  programmer  to  approach 
it  first  as  the  kind  of  formal  language  he  understands  best.  To  help  with 
this,  I include  "programmer’s  manuals"  in  each  of  these  three  tough  ctiapters. 

NASL  has  two  interpreters--  the  theorem  prover  (STP)  through  which  all 
NASL  formulas  must  pass,  and  the  plan  interpreter  (NASL  proper)  wti  i ch  fakes 
some  conclusions  to  be  instructions  to  act.  The  first  design  decision  in 
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expressing  a new  set  of  facts  in  NASL  is  whether  to  rely  entirely  on  STP  or  to 
1 cast  them  as  rules  which  create  and  manipulate  tasks. 

In  principle,  everything  could  be  handled  t;y  the  theorem  prover.  For 

example,  axioms  could  be  introduced  defining  a space  of  electronic  circuits, 

! and  constructively  proving 

' [EXISTS  (X)  (AND  (ELECTRONIC-CIRCUIT  ?X) 

(|P|  ?xm 

could  replace  the  action  (DESIGN  |P|). 

As  we  all  know,  however,  all  theorem  provers  of  STP's  class  rely  heavily 
on  the  generate-and-test  problem-solving  method.  Generating  all  circuits  is 
obviously  ridiculous. 

I Here  are' some  more  general  criteria  for  deciding  whether  to  represent  a 

body  of  facts  as  axioms  or  plans: 

111  As  R.  Moore  (1975)  has  pointed  out,  it  is  a strong  clue  that  a theorem 
prover  is  out  of  place  when  side  effects  enter  naturally  into  the  statement  of 
a body  of  knowledge;  this  is  certainly  true  for  design.  Any  irreversible 
action,  such  as  asking  a question  or  wiring  a circuit,  rules  out  the  use  of  a 
raw  theorem  prover. 

(2)  If  you  wish  to  take  advantage  of  information  relevant  to  a choice 
point,  the  choice  must  come  up  as  the  choice  of  a way  to  do  a task  or  of  the 
, answer  to  a /:FIND.  (You  should  verify  that  the  information  is  worth  the 

j troub I e. ) 

' (3)  If  subgoals  arise  which  must  interact,  you  must  put  the  goals  in  the 

data  pool,  i.e.,  make  them  tasks.  Similarly,  if  you  wish  to  manipulate  goals 
as  data  structures,  you  must  add  rephrasing  knowledge  for  tasks  of  that  type. 

' Only  if  it  appears  that  only  brute-force  deduction  is  necessary  or 

f feasible  should  you  cast  the  knowledge  as  pure  axioms.  An  example  is  the 

[ theory  of  frequency-picture  manipulations  developed  in  Chapter  |V.  Commonly  a 

1 

class  of  tasks  will  be  associated  with  a "mini-theory"  of  some  characteristic 
criterion  for  choosing  between  them;  this  little  theory  is  expressed  in  terms 
of  pure  axiom®.  For  example,  the  theory  of  ordering  the  selection  of 
component  values  with  respect  to  other  tasks  (Chapter  III)  is  a small  set  of 


J 
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axioms.  (The  merits  of  this  "clever  cogitation  directed  by  brute-force 
retrieval"  organization  will  be  discussed  in  Chapter  VI.) 

II.F.I  Predicate-Calculus  Techniques 

Even  after  you  ‘lave  decided  to  represent  a body  of  knowledge  as  a set  of 
facts  about  tasks,  ■ hese  facts  must  be  expressed  as  predicate-calculus 
implications.  The  approach  to  this  that  I have  found  useful  is  to  think  of 
them  independently  of  their  use  first,  concentrating  on  what  they  are  to  mean. 
Once  this  is  done,  the  pragmatic  content  can  be  added.  This  approach  forces 
you  to  think  about  what  you  really  mean  to  express.  For  example,  when  you 
write  an  implication  of  the  form  [|P|  d (/:TASK  ...11,  do  you  really  intend 
that  this  task  exist  only  while  P is  true? 

There  are  three  pragmatic  decisions  to  make:  whether  to  express 
Implication  as  /iCONSEQ,  /:ANTEC,  or  /:GEN;  where  to  use  packets;  and  which 
version  (/:-,  »,  or  -/>)  of  equality  to  use; 

The  first  decision  is  often  simple.  Systems  of  predicate-calculus  rules 
develop  in  such  a way  that  one  layer  of  rules  "feeds"  the  next  during  forward 
and  backward  deduction.  The  rules  usually  work  together  to  record  in  a 
forward  fashion  up  to  a point;  then  backward  (consequent)  rules  work  their  way 
from  deductive  goals  to  the  formulas  recorded  by  forward  rules.  Generative 
("-/>  G")  rules  are  useful  in  mixing  these  processes  up.  So,  for  instance,  it 
is  no  use  having  an  antecedent  rule  if  no  one  records  an  expression  matching 
its  left-hand  side,  R.  Hoore  (1975)  has  given  some  useful  hints  in  deciding 
which  way  implications  can  be  used. 

/:PKT  should  be  used  instead  of  AN9  on  the  right-hand  side  of  an  /:ANTEC 
when  much  of  the  contents  of  the  conjunction  are  not  looked  at  for  most 
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instantiations,  or  if  it  is  not  necessary  that  they  trigger  further  /:ANTECs 
immediately.  This  is  true,  for  example,  of  circuit  diagrams,  where 
information  about  the  purposes  of  components  is  not  always  accessed;  but  not 
true  of  plan  schemata,  where  all  the  tasks  and  subtask  relations  are  going  to 
be  recorded  anyway  (and  the  interpreter  must  notice  every  task). 

It  is  usually  clear  which  version  of  equality  to  use.  Goals  are  usually 
phrase  in  terms  of  but  if  you  know  there  is  only  one  simple  answer,  use 

which  merely  matches  the  two  sides  against  each  other.  Simple  will 
work  harder  in  the  case  where  they  don’t  match.  Often  does  not  have  to 

mentioned  in  the  rules  where  it  it  is  used;  if  rules  like  (»/>  ’ (F  A)  B1  are 
around,  they  will  be  applied  when  the  right-hand  sides  of  implications  like 

(-/>  A (P  ?x)  (0  IF  ?xm 

are  detached  with  the  variables  bound.  That  is,  recording  [P  A)  will  cause  (Q 
B)  to  be  recorded. 

Finally,  remember  that  it  is  not  always  enough  to  supply  axioms  about 

proving  propositions  with  a certain  predicate;  if  you  ever  wish  to  disprove 

such  propositions,  you  musi  supply  appropriate  axioms.  Often  disproof 

information  can  be  summarized  with  a single  PRESUMABLY  statement.  For 

example,  in  the  world  of  blocks,  we  might  have 

[-/>  C (ANO  (ON  ?X  ?Y)  (ABOVE  ?Y  ?ZI)  (ABOVE  ?X  ?ZM 
(-/>  C (ON  ?X  ?Y)  (ABOVE  ?X  ?Y)) 

(PRESUMABLY  ’ (NOT  (ABOVE  ?X  ?Y) ) C) 

The  effort  to  prove  (NOT  (ABOVE  A B)1  will  cause  (via  /:C0NS1STENTLY)  an 
effort  to  prove  A is  above  B;  if  it  fails,  the  conclusion  is  taken  as  true. 
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II.F.2  NASL  Programming  Techniques 


In  applying  NASL  to  a new  problem  domain,  one  must  supply  model- 
manipulation  statements  to  actually  get  things  done,  and  indexed  plan  schemata 
to  orchestrate  them. 

Tasks  may  be  reduced  in  a forward  or  backward  way.  In  the  former,  the 
presence  of  a task  can  trigger  deductions  of  subtasks.  For  example,  in  the 
world  of  blocks,  one  could  specify  a plan  to  the  clear  the  top  of  a block 
thus: 

[-/>  A (/:TASK  ?N  <>  (X  0 (CLEAR  ?X) ) <>) 

(-/>  A (-/>  •(/: TASK-STATUS  ?N)  ACTIVEI) 

(FORALL  (Y) 

(-/>  A iON  ?Y  ?X) 

(S  '(EXISTS  (TI 

(/:TASK  ?T  <> 

(X  0 (PUTON  ?Y  TABLE)  ) 

<>)  m ))] 

(Notice  the  use  of  "S"  to  indicate  that  these  tasks  are  being  triggered,  not 

supported,  by  the  statement  (-/>  ' (/: TASK-STATUS  |task|)  ACTIVEI. I 

In  backward  reduction,  plan  schemata  are  Instantiated  via  /:UO-SUBNET 

calls.  This  requires  a couple  of  formulas.  In  the  same  blocks  world,  ue 

might  have  the  formulas 

(/:  TO-DO  ?TSK  (ACHIEVE  ’(ON  ?X  ?Y)I  <> 

(/: DO-SUBNET  (ACH-ON  ?X  ?Y»  <>)) 

(-/>  A (/:PLAN-INSTANCE  ’PI  (ACH-ON  ?X  ’Y)  ’SUPER-TASK) 

(ANO  (/:TASK  (CLEARER-1  ’PI)  <>  (X  0 (CLEAR  ?X)  ) <>) 

(/:TASK  (QEARER-2  ’PI)  <>  (X  0 (CLEAR  ?Y)  ) <>) 

(/:TASK  (PUTTER  ?PI)  <>  (X  0 (PUTON  ’X  ?Y)  ) <>) 

(/iSUCCESSOR  (CLEARER-1  ?PI)  (PUTTER  ?PD) 

(/:SUCCESSOR  CLEARER-2  ?PI ) (PUTTER  ’PI ))) ) 

The  Interpreter,  when  it  has  decided  to  reduce  [ACHIEVE  ’(ON  ...)I  using  the 

first  ru(e,  will  create  an  instance  of  ttie  schema  (ACH  ON  ...1:  the  second 


rule  will  then  trigger  the  creation  of  several  suhtasks. 
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A corpus  of  NASL  rules  is  often  written  as  an  incomplete  set  of  plans  and 
axioms,  which  is  then  debugged  by  adding  "interaction  terms,"  i,e.,  knowledge 
which  influences  the  application  of  the  first-order  rules.  This  occurs 
through  the  medium  of  these  kinds  of  rules: 

> Rephrasing  rules  which  redescribe  actions,  usually  by  breaking  them  into 
pieces  and  putting  them  back  together. 

> Choice  rules  which  influence  the  way  in  which  tasks  are  reduced. 

> Rules  specifying  /; SUCCESSOR  relations. 

> Policies  to  watch  for  interactions  between  tasks  or  to  influence 
cho i ces. 

Ue  will  see  plenty  of  examples  of  NASL  plans  and  rules  in  the  following 
chapters. 
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III  Design  of  Hierarchical  Systems 

Design  is  the  production  of  an  object  to  satisfy  certain  requirements. 

The  requirements  may  describe  the  desired  object  closely  ("A  stick  10  inches 
long"),  or  they  may  be  very  remote  from  uhat  is  finally  produced  ("Something 
to  make  this  room  look  more  friendly.") 

Of  course,  designing  does  not  mean  actually  manufacturing  an  object:  uhat 
is  actually  produced  is  a detailed  description  of  one.  In  fact,  design  might 
be  described  as  the  process  of  adding  detail  to  a description  until  "full 
detail"  is  reached  relative  to  some  basis. 

In  uhat  follous,  1 uill  elaborate  this  theory,  and  then  explain  hou  it  is 
implemented  as  a set  of  NASL  rules.  (A  close  relative  of  this  theory  uas 

outlined  by  Freeman  and  Neuell  (1971)  in  a paper  called  "A  Model  for 
Functional  Reasoning  in  Design.") 

The  best  uay  to  explain  it  is  to  start  at  the  bottom,  near  the  "basis." 

The  basis  for  a design  domain  is  a set  of  primitive  artifacts.  For  example, 
if  sticks  are  primitive,  designing  a stick  10  inches  long  is  merely  a matter 
of  "instantiating  the  stick  primitive."  "Instantiation"  means  creating  a 
symbol,  such  as  X0A3,  and  recording  that  it  denotes  a stick.  That  is  not  all, 
houever.  Associated  ulth  the  primitive  "stick"  are  attributes  such  as  its 
length,  uidth,  material,  color,  etc.,  uhich  must  be  fixed  for  a concrete 
instance  of  it.  Because  it  is  a primitive,  ue  may  assume  that  fixing  a 
stick's  qualities  is  merely  a matter  of  choosing  them.  (Uooden  sticks  are 
cheaper  than  platinum,  but  I uill  not  consider  cost  explicitly  In  this  paper. 

I emphasize  finding  any  solution  to  a design  problem,  not  finding  the  best 
so  I ut i on. ) 

So  designing  a stick  is  just  a matter  of  picking  a name,  a uidth,  and  a 


Ill  Design  of  Hierarchical  Systems 


91 


length.  (Assuming  brouin  wooden  sticks  from  now  on.)  If  the  length  is 
constrained  to  be  10  inches,  that  is  clearly  the  length  to  pick.  The  width, 
if  unconstrained,  may  be  picked  arbitrarily,  subject  to  the  reasonable 
constraint  on  all  sticks  that  their  width  be  no  more  than  10X  of  their  length. 

For  a primitive  artifact,  then,  "adding  detail"  is  just  selecting  values 
for  its  "control  attributes,"  such  as  length  and  width. 

This  theory  of  design  will  not  account  for  the  design  of  "something  to 
make  a room  more  friendly,"  mainly  because  "object  that  makes  a room  look 
friendly"  is  not  a primitive  artifact  with  a fixed  set  of  attributes.  In 
general,  a requirement  may  be  arbitrarily  remote  in  structure  from  the  kind  of 
object  that  satisfies  it. 

So  it  is  necesary  to  provide  for  for  the  Indexing  of  partial  solutions  by 
their  important  features.  That  is,  the  theory  must  just  provide  for 
statements  I ike, 

"Funny  posters  make  a room  more  friendly." 

"Plants  make  a room  more  friendly." 

"If  X makes  a room  more  friendly,  and  y (distinct  from  x) 

makes  a room  more  friendly,  usually  the  combination  of  x and 
y makes  a room  more  friendly." 

etc. 

A partial  solution  of  this  kind  may  be  a primitive  artifact,  in  which  case 
the  problem  has  been  solved,  but  more  generally  it  consists  of  a structure  of 
design  subproblems.  These  subproblems  must  be  solved  in  much  the  same  way  as 
the  original  problem,  and  the  solutions  must  be  connected  up.  Eventually  the 
original  problem  will  have  been  completely  reduced  to  primitives.  (Fig. 

lil.l) 
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Figure  lll.l  Function-Structure  Graph 
These  primitives  will  be  connected  and  constrained.  Some  of  these 
constraints  come  from  the  problem  (e.g.,  "Amplifier  uith  gain  - IB"), 
from  the  partial  solution  ("A  common-emitter's  gain  is  beta  X 
from  connections  ("The  current  from  is  the  current  into  the  t 

and  some  from  descriptions  of  primitives  ("The  resistanre  must  1 
As  with  the  simple  stick  problem,  the  control  attributes  ' • ••• 
must  all  be  selectetl  subject  to  the  constraints. 

The  design  process  suggested  by  F 1 g.  lll.l  r 
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I 

If  a design  requirement  is  very  simple,  it  is  is  plausible  to  imagine  it 
as  calling  to  mind  a partial  solution  tagged  with  "specs"  which  match  the 
requirement.  For  OKample,  the  design  problem  "flake  a common-emitter 
amplifier"  could  plausibly  match  the  specs  on  the  common-emitter  circuit 
enact ly. 

For  more  complicated  problems,  this  will  not  work.  The  description  might 
contain  conjunctions,  disjunctions,  or  quantifiers.  It  might  consist  of 
simple  pieces  whose  solutions  can  be  composed.  It  may  be  cluttered  with 
numbers  which  have  to  be  described  more  suggestively,  as  in  the  example  of 
Chapter  I,  in  which  "gain  » 10"  was  replaced  by  "moderate  gain."  Finally,  the 
^ description  might  just  be  in  the  wrong  terms;  a common  example  in  electronics 

is  the  translation  between  time-domain  and  frequency-domain  descriptions  of 
signals. 

So  the  theory  must  provide  for  manipulation  of  problem  descriptions, 
before  the  first  partial  solution  can  be  proposed.  This  manipulation  is  aimed 
at  transforming  a description  Into  a form  suitable  for  retrieving  stored 
; partial  solutions. 

I 

• A version  of  this  theory  has  been  encoded  in  NASL.  As  coded,  it  is 

t 

I independent  of  electronics,  although  enough  restrictions  have  been  placed  on 

I i t to  keep  me  from  claiming  it  is  a complete  general  design  theory.  It  is 

meant  to  be  a theory  of  engineering  design,  for  which,  to  first  order,  all 
effects  can  be  thought  of  as  local  interactions  among  connected  modules,  each 
i of  which  is  designed  to  accomplish  some  part  of  an  overall  objective.  It  is 

I biased  toward  systems  whose  interactions  can  be  described  numerically.  I will 

call  this  domain  "design  of  hierarchical  systems." 

It  is  straightforward  to  express  in  NASL  most  of  the  concepts  I have 
outlined^  The  first  step  is  to  impiement  the  notions  of  "requirement"  and 

i 


i:- 
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"structure  fulfilling  it"  as  tasks  and  subtasks.  That  is,  a design  problem  is 
expressed  as  a task,  and  the  terminal  nodes  of  the  function-structure  graph 
are  to  be  identified  with  primitive  tasks  of  the  form  "grab  a (primitive) 
component."  For  example,  a first-pass  anali;3is  of  an  electronics  problem  may 
generate  this  structure: 


Acquire 
Stage  1 


Q Make  a cascade 


O 


O 


O Couple 


Acquire  Stage  2 


Figure  1 1 1.2  A Tuo-Stage  Cascade 
Later  elaboration  ui  I I instantiate  the  coupling  task: 
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Figure  1 1 1.3  An  LC-coupled  Amplifier 
"Partial  solutions”  are  implemented  as  a Kind  of  plan  schema.  A 
particularly  important  kind  of  partial  solution  is  a device  type,  a packet  of 
facte  clustered  around  a concept  like  "amplifier,"  or  "operational  amplifier," 
or  "resistor."  Some  of  these  facts  describe  the  structure  of  the  devices  of 
the  given  type,  but  many  of  them  are  concerned  uith  how  such  devices  are  used 
in  solving  larger  design  problems.  This  last  set  of  facts  defines  a set  of 
tasks  for  elaborating  a device  and  connecting  it  to  its  peers. 

Primitive  devices  are  those  with  no  internal  structure,  whose  elaboration 
consists  mainly  of  selecting  values  for  their  control  attributes.  The  system 
represents  these  obligations  as  a set  of  "SELECT-VALUE"  tasks.  The 
constraints  that  accumulate  during  a design  are  implemented  as  policies  which 
influence  the  eMecution  of  SELECT-VALUE  tasks. 
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Because  we  are  using  the  NASL  interpreter,  all  design  subproblems  are 
represented  eKplicitly  in  the  data  base  as  tasks.  Partial  solution  plans  are 
recovered,  as  for  all  tasks,  by  using  STP  to  retrieve  them.  Choice  rules  are 
used  to  choose  among  or  compose  sets  of  partial  solutions.  Simultaneous 
subproblems  are  represented  by  simultaneously  active  tasks.  There  are 
frequent  cases  where  it  is  important  to  start  on  one  problem  before  another, 
because  the  solution  to  the  first  will  influence  the  choice  of  approach  to  the 
other.  This  can  be  arranged  by  writing  rules  to  cause  the  deduction  of 
/jSUCCESSOR  formulas. 

The  manipulation  of  requirement  descriptions  when  routine  indexing  fails 
to  retrieve  a partial  solution  is  handled  by  a special  design  rephrasing  plan. 
It  says  to  turn  a recalcitrant  design  task  into  a task  network  of  the 
following  kind  (cf.  Fig.  1 1 1. 8):  make  a device  of  a known  type,  and  constrain 
it.  The  plan  is  to  do  this  by  tearing  the  given  problem  into  pieces  called 
"shards"  (usually  conjuncts  from  the  design  requirement),  each  of  which  is 
classified  as  specifying  either  the  device  type  or  a constraint.  The  plan 
succeeds  only  if  every  shard  is  accounted  for  in  one  of  these  ways.  It  is 
generally  the  responsibility  of  rules  from  domain-dependent  plans  to  make  sure 
this  is  true.  In  the  electronics  domain,  as  we  shall  see.  there  are  many 
rules  for  manipulating  shards,  ranging  from  those  which  convert  shards 
regarding  gain  into  control-quant  i ty  constraints,  to  those  which  change 
a i gna I -conver s i on  shards  from  the  time  domain  to  the  frequency  domain. 

This  is  a broad  outline  of  the  design  theory  encoded  in  the  formal  theory 
of  OESI.  (Appendix  2)  A point  to  notice  in  its  exposition  is  that  I appealed 
to  innate  control  concepts  to  explain  notions  of  structure,  purpose,  and 
constraint.  It  will  be  seen  that  appeals  like  this,  appropriately  formalized, 
are  the  only  kinds  of  knowledge  of  these  concepts  that  OESI  has.  In  a 
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i 
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primitive  May,  the  program  exhibits  "machinomorphiam, " the  inclination  to 
understand  other  systems  in  terms  of  its  oun  Kinds  of  motives.  This  al lous  a 
certain  computational  economy,  and  makes  assimilation  of  neu  information  more 
reliable  by  enforcing  a small  vocabulary.  A complicated  and  delicate  (or 
electronics-dependent)  theory  of  purpose  and  commitment  does  not  have  to  be 
added  by  the  user. 

Before  turning  to  a detailed  exposition  of  the  OESI  implementation,  I 
should  mention  three  issues  I ui  1 1 have  little  to  say  about:  learning,  search, 
and  creativity.  The  last  of  these  may  seem  the  most  important.  tiany  people 
Mould  probably  be  skeptical  about  the  ability  of  a machine  to  do  design, 
because  creativity  seems  to  be  absent  from  machines  and  vital  to  design. 
Indeed,  "design”  and  "creativity"  seem  almost  to  be  defined  in  terms  of  each 
other.  If  this  issue  bothers  you,  let  me  call  your  attention  to  the 
distinction  betueen  "routine"  and  "imaginative"  design.  Routine  design  is  the 
production  of  an  artifact  in  a field  (such  as  electronics)  such  that  anyone 
else  Mith  an  ordinary  mastery  of  the  field  could  have  produced  the  same  thing. 
This  kind  of  design  is  the  only  kind  I can  claim  to  have  a theory  of. 

OESI  does  not  learn  anything  from  doing  a design.  Although  at  the 
beginning  of  this  chapter  I described  designing  as  adding  more  detail  to  a 
description,  the  description  at  the  end  of  a design  is  not  represented  the 
same  May  as  the  problem  description.  The  problem  description  is  essentially  a 
X-expression,  but  the  final  result  is  a set  of  statements  in  the  data  base 
about  "X043,”  or  Mhatever  symbol  uas  chosen  to  represent  the  target  device. 

To  learn,  OESI  Mould  have  to  gather  these  statements  together  into  a neu  plan, 
and  index  it  under  a useful  generalization  of  the  problem.  Doing  this  is 

V 

difficult.  (Cf.  Sussman,  1975) 

Other  kinds  of  learning  are  also  possible.  One  can  imagine  a program 
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learning  hoM  to  order  certain  Kinds  of  subproblems,  or  hou  to  choose  and 
compose  partial  solution.  These  are  examples  of  "trial  and  error"  learning; 
to  attacK  them  requires  a theory  of  search. 

DESI,  like  all  NASL  ^ystems,  tries  never  to  make  a choice  at  random,  and 

never  backs  up  to  undo  choice.  (See  the  discussions  in  Chapter  I!,)  Thus, 

il 

it  can  be  said  not  to  search  at  all.  This  is  the  right  organization,  but  it 
needs  to  be  combined  with  a learning  eystem  that  proposes  new  choice 
principles  by  watching  what  happens  after  it  does  make  an  arbitrary  choice. 

For  example,  if  one  amplifier  circuit  is  chosen  from  several  that  satisfy  the 
known  choice  principles,  and  later  its  impedance  is  discovered  to  be  too  high, 
the  system  should  not  back  up,  but  should  make  up  a new  choice  principle  to 
rule  that  circuit  out  in  case  high  impedance  is  required. 

The  system  currently  does  none  of  these  things.  If  its  rules  get  it  into 
trouble,  it  will  look  for  a correction  plan  that  fits  the  situation,  but  will 
do  the  same  thing  all  over  again  if  the  next  problem  is  similar.  This  is  a 
serious,  but  (I  hope)  temporaray,  defect  in  the  theory,  since  it  seems  clear 
that  people  learn  something  new  in  the  course  of  all  but  the  most  routine 
design  tasks. 

As  I describe  in  detail  DESI  ’ s design  theory,  I will  point  to  the  more 
formal  exposition  of  Appendix  2.  By  looking  there,  you  will  be  able  to  judge 
the  power  of  the  NASL  control  language.  It  will  be  seen  exactly  how  often  it 
ie  directed  and  flexible,  and  how  often  clumsy,  arbitrary,  or  inextensible. 

The  important  point  at  issue  during  this  otherwise  tedious  exercise  is  one's 
ability  to  represent  various  specialized  control  and  debugging  strategies 
using  the  framework  of  tasks,  data-dependencies,  and  conflicts  described  in 
Chapter  II.  In  what  follows,  references  to  the  formulas  of  Appendix  2 are 
indicated  thus;  <*formula-nam>. 
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111. A The  Representation  of  Knouledge  about  Devices 

Much  of  design  is  the  manipulation  of  devices.  A device  Is  any 
manipulable,  "physical"  object  in  a design  domain.  (Thus,  signals  will  not  be 
devices,  but  nodes  will  be.)  Familiar  classes  of  devices  that  are  useful  are 
called  device-types.  These  classes  may  be  formed  in  several  ways.  (Sect. 
III.A.l)  Each  device  in  a class  is  described  by  a set  of  formulas  arranged  in 
certain  standard  ways.  (Sect  I II. A. 2)  A set  of  formulas  describing  a device 
type  is  instantiated  to  form  a particular  device's  description.  Knowledge 
about  a device  type  is  therefore  conveniently  represented  as  a "packet" 
(McDermott,  1975)  of  facts  which  is  instantiated  when  a particular  example  is 
considered.  This  packet  is  called  a device  schema.  (Unfor tunately.  Brown  and 
Sussman  (1974,  A.  Brown,  1975)  have  used  the  term  "plan"  for  this  purpose. 

This  conflicts  with  the  usual  range  of  meanings  of  this  term  in  Al.  I have 
used  this  term  in  the  more  traditional  meaning  already  in  discussing  the 
interpreter. ) 

III.A.l  Hierarchies  of  Device  Types 

Device  types  which  have  a recognizable  function  and  circuit  diagram  (or 
symbol)  are  called  basic.  Basic  device  types  may  be  lumped  into  loose  classes 
called  superordinate  device  types.  <*DEVICE-CLASSES>  (This  terminology  is 
borrowed  from  (Bobrow  and  Uinograd,  197B),  but  I am  not  sure  I mean  the  same 
thing  by  it  that  they  do.)  Sometimes  such  a higher  class  exists  just  because 
people  have  a name  for  it  and  use  it  to  specify  problems.  An  example  is 
"amplifier.”  Sometimes  there  is  some  class  of  facts  it  is  convenient  to  store 
together,  as  for  "2-terminals."  (See  Chapter  IV.) 
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Kinds  of  Device  Type 
Basic 

Primitive  (e.g.,  resistor) 

Composite  (e.g.,  common-emitter  amplifier) 

General 
Special ized 

Ideal  le.g.,  current  source) 

Superordinate  (e.g.,  amplifier,  2-term  nal) 

Figure  1 1 1.4  A Hierarchy  of  Types  of  Device  Types 

Basic  device  types  may  be  further  classified  <*BASIC-DEViCE-rLA5SE5>  as 
primitive,  composite,  and  ideal.  Primitive  devices  are  the  terminals  of  a, 
complete  funct ion-structure  graph.  (See  below.)  Ideal  devices  such  as  current 

and  voltage  sources  behave  as  primitive  devices,  hut  must  be  "implemented." 

Canned  devices  that  are  made  up  of  simpler  components  are  called  composite 
device  types.  Textbook  diagrams  of  things  like  Hartley  oscillators  and 
common-emitter  amplifiers  may  be  taken  as  standard  examples  of  composite 
device  types.  Dften  these  textbook  diagrams  leave  implicit  what  I take  as  an 
important  feature,  that  they  exist  in  general  and  specialized  versions.  (Fig. 

1 1 1. 4)  <*GENERAL-DEFN>  The  general  common-emitter  amplifier,  for  instance,  ie 
just  a transconductance  treated  in  a certain  way,  whereas  the  "typical  common- 
emitter"  has  biasing  resistors  hung  all  over  it.  (Cf.  Uatson,  1970)  This  is 
expressed  as 

(DERIVED  TYPICAL -CE  GENERAL -CE ) . 

The  importance  of  this  relation  will  be  brought  out  shortly. 

Thus  a particular  device  will  be  at  the  bottom  of  a hierarchy  of  general 
and  superordinate  devices.  (Fig.  1 1 1.5) 
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Figure  1 1 1.5  Devices  in  The  Type  Hierarchy 
The  relation  betueen  the  devices  above  the  BASIC  level  in  Fig.  1 1 1.5  is  ISUB- 
OEV-TYPE  |dev  type|  | superordinate  dev  type|I.  Below  that  level,  the  relation 
is  ISPEC-DEV-TYPE  I specialized  dsv  type(  |dev  typejl.  Thus  we  would  write 
ISUB-OEV-TYPE  COnOON-Eni TTER  AnPLIFIER)  and  ISPEC-DEV-TYPE  TYPICAL-CE  COmON- 
EMITTERJ.  (The  DERIVED  relation  will  be  explained  below.  Sect.  III. A. 2.) 

A device  will  be  of  several  device  types,  written  IDEV-TYPE  |dev|  |type|l. 
There  is  usually  one,  its  flAIN-OEV-TYPE,  which  is  the  most  specific  category 
it  Is  known  to  fal I in. 


I II. A. 2 The  Representation  of  Device  Diagrams 

A device  Is  either  primitive  or  composite,  depending  on  its  main  device 
type.  A device  is  specified  with  several  Kinds  of  information  (most  of  them 
are  not  necessary  for  primitivs  and  ideal  devices): 


•4 
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(1)  The  components  of  devices  of  that  type.  This  is  kept  in  formulas  of 
the  fore 

ICOtlPONENTS  1 dev  ice  I < -component  names-  >1 

Each  component  is  itself  a device,  whose  main  device  type  is  expressed  by  a 
separate  formula.  For  example,  for  a voltage  divider  VD/fZl  we  might  have 

[COnPONENTS  V0#2I  <(R1  V0»2l)  (R2  VD/f21)>l 
[MAIN-DEV-TYPE  (Rl  VD«21)  RESISTOR! 
mAIN-DEV-TYPE  IR2  VD#21)  RESISTOR] 


(2)  Connections  and  constraints  between  components.  There  can  be  no 
doma i n- independent  notion  of  connection  between  physical  objects,  since  any 
physical  medium  can  be  exploited.  The  only  completely  general  thing  that  can 
be  said  is  that  connecting  devices  "constrains”  them  in  some  way. 

(Otherwise,  there  would  be  no  point  in  connecting  them.  Cf.  "CONSTRA I NT2"  in 
Fig.  1 1 1.1.)  As  we  shall  see  below,  there  is  a rich  theory  of  constraints 
built  into  DESI . 


(3)  Control  quantities.  These  are  numerical -valued  attributes  of  the 
device  that  the  designer  has  complete  or  partial  control  over.  They  are 
represented  by  formulas  like 

(CONTROL  |attribute|  |device|  |range|  |degree  of  control |). 

This  declares  attribute  to  be  a control  attribute;  it  means  that  the  quantity 
(|attribute|  |device|l  may  be  assigned  any  value  from  the  set  of  ni'-^bers 
range.  Since  real  components  often  vary  from  their  nominal  values,  the 
formula  specifies  the  degree  of  control  of  the  attribute,  which  is  the 
quotient  of  the  highest  and  lowest  possible  true  values  compatible  with  the 
selected  value  that  appears  in  the  data  base.  This  value  is  actually  the 
(geometric)  mean  of  highest  and  lowest  values.  These  uncertainties  will  be 
taken  into  account  in  reconciling  constraints.  As  an  example,  in  electronics 
for  a transistor  Q#173  we  might  have 

(CONTROL  BETA  Q/lfl73  (INTERVAL  10  500)  10). 

since  the  beta  of  a transistor  is  controllable  only  to  within  an  order  of 
magnitude:  while 

(CONTROL  POLARITY  Q»173  <♦!  -1>  1). 

since  every  transistor  is  unambiguously  PNP  or  NPN. 

A distinction  must  be  made  between  Immediate  control  quantities  and 
derived  control  quantities,  corresponding  roughly  to  attributes  of  primitive 
and  composite  devices.  There  are  several  relevant  formula  types  for 
expressing  information  about  these  matters: 


(a)  (IflflEDI ATE-CQ  ’Icontrol  quantity|l 

Example:  IinMEDI ATE-CQ  ’(RESISTANCE  R«21)l 
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(b)  IDERIVED-CQ  * Icontrol  quantity|l 

EKample:  lOERIVED-CQ  ’ (V-GAIN  Af1P#3A))  The  actual  function 
relating  the  V-GAIN  of  the  amplifier  to  the  values  of  its  components' 
control  quantities  can  be  derived  from  constraints  found  in  the 
description  of  AI1P<f34.  Often  these  will  be  found  in  the  device  schema  of 
which  AI1P/Sf3A  is  an  instance. 

(c)  IGENERIC-CA  |attribute|l 

Example:  IGENERIC-CA  THEV-R]  It  would  be  tedious  and  wasteful  to 
derive  a formula  for  each  device  or  device  schema  relating  its  Thevenin 
resistance  to  its  components’  values.  (A  change  of  topology,  for 
instance,  would  force  a recomputation.)  Instead,  some  control  attributes 
can  be  declared  generic,  meaning  the  system  knows  how  to  compute  them  and 
will  when  they  are  needed.  (The  current  system  can  handle  this  to  the 
point  of  enqueueing  a CALCULATE  task,  but  the  computational  techniques 
required  have  not  been  implemented.) 


(A)  Task  Information.  Every  device  has  a cloud  of  tasks  floating  around 
it.  These  will  be  of  various  sorts: 

> The  purposes  of  a device  and  its  components  are  represented  by  a set 
of  finished  tasks  associated  with  acquiring  them. 

> Many  devices  will  not  function  as  they  are  supposed  to  without  further 
work  I" subrequ i r ement s"  in  Fig.  III.l);  these  active  tasks  are  called 
expansion  obligations.  These  ride  along  on  most  composite  devices  and  even 
some  primitive  ones;  a transistor,  for  example,  must  be  biased  into  its 
intended  mode. 

> A device  carries  along  monitors  on  the  topology  of  the  connections 
inside  it  and  from  it  to  other  devices;  some  of  these  monitors  are  for 
protection  of  important  relationships,  and  some  just  to  notice  when  something 
must  be  recomputed. 


These  are  characteristics  of  devices.  A device  schema  is  merely  a canned 
set  of  such  formulas  with  a free  variable  to  be  bound  to  a particular  device 
when  it  is  made.  Device  schemata  are  used  to  represent  device  types.  They 
are  usually  implemented  as  "packets."  (McDermott,  1975)  For  example,  the 
packet  for  "voltage  divider"  will  include  the  formula 
(COMPONENTS  ?/»«VD  <(R1  ?#<fV0)  (R2  ?mD)>) 
from  which  the  formula  given  above  for  VD<(21  will  be  derived.  The  prefix 
"?<(#"  specifies  ttiat  ?h/(VD  is  a variable  loosely  bounti  to  an  "abstract  voltage 
divider,"  The  formula  says,  "the  typical  VD  ?X  has  components  (R1  ?X)  and  IR2 
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?X1 . ") 

The  tasks  that  wiill  be  liberated  uhen  a device  schema  is  instantiated  are 
called  frozen  tasks,  and  the  liberation  process  is  called  "thauing."  Frozen 
tasks  may  be  thought  of  as  mummified  remnants  of  actions  that  were 
(conceptually)  executed  uhen  the  device  schema  uas  first  put  together. 

(Device  schemata  are  to  be  thought  of  as  the  result  of  previous  designing 
activity  folloued  by  summarizing  uhat  .-as  learned,  but  this  is  just  to  help 
your  imagination;  such  a learning  scheme  do'^sn’ t exist  yet.)  One  thing  that 
must  be  left  around  in  a schema  is  a record  of  uhy  the  various  com|)onents  uere 
acquired  and  connected  as  they  are  nou  found;  in  other  uords,  the  purposes  of 
the  components.  (If  for  no  other  reason,  these  are  necessary  in  case  they 
have  to  be  undone  during  mistake  correction.) 

The  simplest  uay  to  accomplish  this  is  to  keep  the  tasks  that  uere  knoun 
at  the  end  of  the  (imagined)  design  episode  in  a frozen  state.  Some  of  these 
uill  have  been  FINISHED;  for  example,  the  tasks  that  acquired  the  components 
are  there  just  to  record  uhy  they  uere  acquired.  Others  are  still  active. 

For  example,  there  uill  be  ACTIVE  constraints  am)  protected  model 
man i pu I a t i ons. 

By  uay  of  illustration,  a voltage  divider  may  be  firs*  ;tum,,b*  of  as  a uay 
of  setting  a bias  voltage  in  a particular  amplifier  design  problem.  A voltage 
divider  found  in  a schema  must  be  associated  uith  a pol'cy  of  ke#giirM|  *b,«* 
bias  vol tage  set. 

An  advantage  of  the  frozen  policy  solution  comp.^red  to  a more  spei  t .-ea 
implementation  of  purpose  comments  is  that  one  mecha.i.sm  is  user*  *o  b.f  i r- 
local  cooperation  and  conflict  of  tasks  as  uel  l as  interactions  of  nr»u  *•  tions 
uith  old  purposes.  This  is  an  example  of  the  “machinomorphi  sm"  | mentioneil  at 
the  beginning  of  this  chapter. 
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Specialized  device  types  are  arranged  in  a hierarchy  according  to  the 
DERIVED  relation.  This  is  a more  complex  relation  than  SUB -OE V- T Yf’E  anri  5PEC- 
DEV-TYPE  (cf.  Fig.  III. 5),  which  are  used  mainly  to  cause  properties  of  higher 
types  to  be  inherited  by  lower.  <*SUB-DEV-TYPE-1 , SPEC-DEV-TYPE-1  > Most  of 
the  properties  of  a general  circuit,  such  as  its  topology  and  components,  are 
not  to  be  inherited  by  its  specializations.  However,  there  is  an  important 
class  of  properties  which  must  be  accessible  from  the  specialization:  the 
frozen  tasks  of  its  more  general  counterpart.  The  relation  between  a general 
circuit  and  its  specialization  is  precisely  that  the  expansion  obligations  of 
the  gerteral  circuit  are  fulfilled  by  the  structure  of  the  specialization. 

To  represent  this  relation,  we  need  some  more  equipment.  Every  device 
thawed  from  a schema  has  a "deep  freeze"  of  frozen  tasks,  which  are  collected 
for  convenience  as  the  subtasks  of  an  abstract  task  called  the  IDEEP-FREEZE 
|device|].  If  dev-type  1 is  derived  from  dev-type  2,  then  a device  of  type  1 
will  have  a "SOUL"  which  is  a device  of  type  2.  <*S0UL-0N-ICE>  The  important 
relation  between  them  is  that  every  subtask  of  the  soul’s  deep-freeze  is  to  be 
a subtask  of  the  original  device’s  deep-freeze.  This  inheritance  is  done  via 
/iCONSEQ  deduction,  since  it  is  not  important  to  see  every  frozen  task  during 
normal  operation;  most  of  them  will  have  been  reduced  anyway.  They  c s mainly 
valuable  in  explaining  the  purposes  cl  components. 

For  many  examples  of  device  schemata,  see  Appendix  3. 


Ill  Design  of  Hierarchical  Systems 


106 


I M .B  Design  Actions 


and  Plans 


I can  go  no  further  in  talking  about  devices  uithout  talking  about  design 
actions.  This  is  because  devices’  purposes  are  so  intimately  associated  with 
the  purposes  of  their  designer,  in  this  case  DESlt  and  OESI’s  purposes  are 
expressed  as  tasks. 

Design  actions  fall  naturally  into  these  classes  (see  Fig.  111.6): 

(1)  "Design  something  with  property  p";  Starting  with  no  structure  or  hint 
of  it,  one  is  to  produce  such  a thing. 

(2)  "Hake  an  x":  Here  x is  a device  type,  an  example  of  which  is  to  be 
created.  This  kind  of  action  breaks  down  into  subtypes,  depending  on  what 
kind  of  device  type  x is.  Making  a basic  type  tends  to  be  a matter  of 
choosing  which  version  along  the  specialization  scale  to  use,  then  plugging  in 
its  frozen  tasks.  Making  a superordinate  type  requires  more  involved  and 
careful  choice,  since  the  sub-types  to  choose  from  usually  have  incompatible 
proper  ties. 


(3)  "Constrain  something":  Things  that  can  be  constrained  are  not  devices, 
but  quantities.  There  are  two  classes:  physical  quantities  such  as  voltages 
and  currents;  and  the  control  quantities,  such  as  resistances  and  power  gains, 
that  I described  above. 


(4)  "Change  a device":  Given  a structure,  it  can  be  altered  in  various 
ways.  These  actions  include  fixing  a physical  quantity,  biasing  a circuit, 
adding  feedback  to  improve  stability,  and  coupling  two  stages.  The  actions 
are  defined  by  plan  schemata  that  often  come  in  specialization  hierarchies 
like  those  of  devices,  A major  subdivision  of  these  are  actions  which  involve 
changing  the  previously  reigning  plan  network  as  well,  for  example,  altering  a 
control  quantity  which  is  already  fixed  by  constraints. 

This  list  is  derived  by  common  sense,  and  from  perusal  of  100  Ideas  for 


Design  (Electronic  Design,  1964),  among  other  works,  (Senturia  and  Uedlock, 


1975) 
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Design  Actions 

1 DESIGN 

2 HAKE 

superord i nate 
primitive 
i dea  I 
general 
special ized 

3 Constrain 

CDNS TRAIN 
SELECT -value 

A Change 

F I X quant i ty 
BIAS 
COUPLE 
Patch 

IMPROVE  gain,  input-Z,  selectivity,... 

Figure  III.G  Design  Action  Taxonomy 

The  design  problems  uhich  appear  in  books  such  as  these  include 

"Design  a power  amplifier..."  (Type  2) 

"Increase  the  current..."  (Type  A) 

"Isolate  two  connected  devices"  (Type  A) 

"Make  tne  quiescent  output  voltage  A0V"  (Type  3) 

"Design  a circuit  with  a high  gain-bandwidth  product"  (Type  1) 

"Avoid  loading"  (Type  3) 

(There  are  other  kinds  of  actions,  such  as  "simplify  a circuit,"  which  I have 
not  counted  as  among  these  types.  I hope  they  can  be  added,  but  I have  no 
plans  to  do  so. ) 


III.B.l  OESIC^ 


There  is  only  one  action  in  this  class. 

((3ESIGN  Ipropi)  — > (<|name|>) 

This  action  usually  arises  at  the  top  level.  Successful  execution  of  such 
an  action  creates  a model  of  a device  that  has  property  prop.  In  easy  cases. 


t 
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this  reduces  quickly  to  an  action  of  Type  2.  <*EASY-DESIGN> 

In  the  hard  cases,  processing  turns  upon  a large  body  of  domain-dependent 
rephrasing  knouledge,  directed  by  the  rephrasing  plan  DES I -REPHRASE -PLAN. 
<*-fOESI-l,  +0ESI-2>  This  plan  network  may  be  graphically  enpressed  as 
fol lows: 


-4 


O^ind  d- features 
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predicate  as  the  value  of  7-t-P.  In  this  context,  the  embedded  formulas, 
prefixed  with  the  character  are  being  used  essentially  as  SNOBOL  patterns 

(Farber  et.  a?.,  1964)  to  tear  the  goal  to  be  rephrased  into  manageable 
pieces.  So  ?+P  will  have  value  [(|prop|]].  (See  Appendix  1.) 

Remember  that  the  final  aim  of  a rephrasing  task  is  a revealing  reduction 
of  its  target  task.  A detailed  analysis  of  the  problem  may  be  postponed;  the 
important  thing  in  rephrasing  is  to  make  it  "familiar."  The  goal  in  the  case 
of  Jhe  design  rephrasing  plan  is  to  reduce  the  design  problem  to  the  following 
neti 


Side -tasks 

(usually  CONSTRAINS) 


Figure  1 1 1.8  Rephrased  Design 

The  strategy  of  the  designer  is  to  "explode"  the  given  predicate  into  "d- 
shards,"  which  are  conjuncts  of  the  original  predicate.  Discovering  d-shards 
Is  occasionally  straightforward  <*0-SHAR0>,  but  usually  depends  upon  formulas 
for  the  domain  involved.  (See  Chapter  IV.) 

The  d~shards  are  valuable  only  insofar  as  they  lead  to  one  of  three 
things: 

(1)  A core-device-type  the  MAKing  of  which  is  the  simple  first  step  of  the 
rephrased  design  plan  (Fig.  1 1 1. 8); 

(2)  Side-tasks,  typically  to  enforce  numerical  constraints  discovered  as 
d-shards; 

(3)  D-features,  qualitative  predicates  used  as  policies  in  making  a core- 
device-type. 

This  fact  is  expressed  as  the  policy  task  ACCOUNT -FOR- ALL.  which  says  to 


■d 
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make  sure  that  every  d-shard  leads  to  one  of  these  three  things.  In  the 
current  implementation,  it  is  an  error  if  a miscreant  shard  is  d i scover  erl.  A 
mdre  sophisticated  implementation  would  know  how  to  try  harder  arid  attempt  to 
learn  from  its  efforts. 

The  only  other  feature  of  interest  in  the  general  design  rephrasing  plan 
is  the  step  CORE-FINOER,  during  which  NASL  must  find  the  core  device-type  to 
be  used.  The  core  device  type  is  often  clear  from  a d-shard  of  the  form  I IX 
(DEV-TYPE  ?1^|  |dev-type| ) ] 1 <*C0RE-DT-1>.  However,  rules  from 
particular  domains  can  and  do  suggest  device-types  based  on  more  elaborate  d- 
shard  processing.  The  interpreter  must  choose  one.  It  is  the  responsibility 
of  the  writer  of  this  knowledge  to  provide  choice  rules  to  get  out  of  this 
situation.  However,  there  is  one  rule  <*C(DflE-DT-CHOOSE>  which  is  domain- 
independent:  if  one  device  type  is  subordinate  to  another,  reject  it.  (It 
should  be  suggested  later  anyway  by  the  policies  that  grow  out  of  d-features.) 

This  rephrasing  method  may  be  compared  with  the  proposal  of  Moore  and 
Newell  (197A)  for  the  MERLIN  program.  The  idea  there  was  to  be  able  to  "view" 
any  conceptual  structure  as  another  by  a process  of  mapping  the  pieces  of  one 
into  the  pieces  of  the  other.  DESI  tries  to  view  any  design  problem  as 

"making  a ....  while  noticing  hints  *■**,  then  doing this  template  may  be 

seen  as  a three-slotted  structure,  such  that  every  piece  ("d-shard")  of  a 
design  problem  goes  into  one  of  these  slots.  The  process  is  more  structured 
than  MERLINj  in  particular,  this  kind  of  rephrasing  is  not  an  operation  which 
can  always  be  done  by  definition;  it  is  capable  of  failing.  The  analogy  may. 
however,  be  revealing.  (It  was  su^  *sted  by  Marvin  Minsky.)  I suspect  that 
many  rephrasing  problems  can  he  put  in  this  paradigm  form,  and  that  the 
rephrasing  protocol  can  be  made  more  specific.  However,  currently  DESI  does 
things  with  rephrasing  which  cannot  be  seen  as  an  instance  of  this  paradigm. 


4 


Ill  Design  of  Hierarchical  Sgsfems 


112 


(An  eKanple  is  equation  solving. I 
IIl.B.2  MaKing  Things 

(1)  [MAKE  I dev  ice  type|l  ->>  [<|name|>} 

The  intent  of  this  action  is  to  create  ("buy")  a device  of  the  indicated 
type.  If  the  device  type  is  basic  <*f1AKE-BASIC-PLAN>.  a task  net  is  set  up 
with  a primitive  GRABBA  action,  which  will  just  generate  a new  symbol  ant)  make 
its  main-dev-type  be  the  basic  type.  Extra  tasks  are  hung  on  the  network, 
depending  on  whether  the  device  is  primitive  <*f1AKE-PRIf1>,  composite  <*f1AICE- 
C0t1P0SITE>,  or  ideal  <*f1AKE-IDEAL>.  In  the  case  of  primitive  devices,  the 
only  commitment  enqueued  is  to  select  the  values  of  its  control  quantities. 

In  the  case  of  composite  devices,  the  plan  subnetwork  includes  a sub  task  to 
expand  the  device  at  some  time  in  the  future.  Ideal  devices  receive  a 
commitment  to  be  implemented.  (These  new  tasks  are  not  marked  /:MAIN  in  their 
task  networks,  so  they  do  not  have  to  be  finished  before  the  successors  of 
their  supertasks  are  begun;  hence,  they  amount  to  future  commitments.) 

Expansion  of  a composite  circuit  means  wiring  up  a circuit  diagram  for  it. 
Usually  this  just  means  selecting  a specialized  device  type  and  declaring  the 
circuit  to  be  that  type:  this  is  called  "specializing"  the  circuit. 

<*SPECI ALIZE-OEFN>  The  system  has  a choice  of  circuit  diagrams  from  the 
specialization  hierarchy.  If  one  circuit  is  DERIVED  from  another  (and  hence 
is  "specialized”:  see  Figs.  III. A and  111.51,  it  will  do  the  same  task,  but 

may  depend  on  more  specialized  assumptions.  It  is  the  user’s  job  to  write 
rules  that  suggest  circuit  versions  to  match  requirements,  but  the  system 
knows  about  two  peculiar  specializations  of  a circuit:  its  "most  general" 
specialization  and  its  default  specialization.  <*f10ST-GENERAL-DEFN,  DEFAULT- 
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SPEC-OEFN>  It  either  of  these  is  available,  it  will  be  suggesterl.  Generally, 
only  one  specialized  device  type  of  some  basic  type  will  come  up  in  a given 
context.  The  user  must  make  sure  that  good  choice  rules  are  available  when 
more  than  one  appears.  The  trade-offs  should  be  clear:  a general  schema 
involves  more  work  on  expansion-obligations,  but  using  a specialized  version 
runs  the  risk  of  having  to  correct  the  circuit  topology  when  some  assumption 
proves  unjustified. 

If  the  user's  rules  do  not  sufficiently  disambiguate,  the  system  uses  the 
two  rules  <*SPEC-DEV-BETTER,  TUO-SPEC-OEVS-UORSE-THAN-ONE>.  The  first 
encourages  the  use  of  a more  specialized  device  type  if  it  has  been  suggested; 
the  second  overrides  this  one  by  ruling  out  conflicting  suggested 
special izat ions. 

Basic  device  types  are  just  canned  diagrams;  the  choice  is  which  version 
of  essentially  the  same  circuit  to  take.  That  is  why  these  special  cases  can 
be  distinguished.  In  choosing  among  superordinate  devices,  rules  for  zeroing 
in  on  basic  sub-types  are  entirely  up  to  the  user. 

(21  (ACQUIRE  (device  type|)  -->  t<|name|>) 

HAKE  a device  type,  unless  there  is  already  one  around  which  can  be  used. 
<*AC(XJI RE-(X)-1 , ACQUI RE-D0-2>  For  example,  you  should  always  re-use  old 
voltage  sources  instead  of  making  a new  one;  you  should  never  re-use  a 
transistor;  and  you  should  look  around  to  see  if  you  can  bum  a node  before 
making  a new  one.  (This  last  information  is  purely  domain-dependent.  See 
Appendix  3. 1 


Ill  Design  of  Hierarchical  Systems 


(3)  (EXPAND  I dev i cell 

This  action  is  required  for  devices  which  are  not  fully  specified  by  their 
circuit  diagrams.  (See  below.  Sect.  III. A. 2.)  This  task  doesn’t  require 
elaboration,  but  accumulates  subtasks  by  deduction.  For  example,  it  picks  up 
expansion  obligations  from  composite  device  schemata.  These  are  actions  which 
become  subtasks  of  the  task  of  EXPANDing  each  instance  of  the  device. 
<*EXPANSI0N-(3BLS-D0>  Dther  tasks  that  are  created  involve  finding  all  GENERIC- 
CA’s  of  the  device  that  have  been  constrained  and  deriving  the  formulas  which 
define  them.  <*CENERIC-CAS-DD>  (See  Sect.  IV.B.4.) 

14)  (CONFIG  < -types-  > 

(A  (-vars-)  < -actions-  > )) 

This  is  a "macro-action"  which  is  an  abbreviation  for  "ACQUIRE  the  types, 
then  bind  the  vars  to  the  resulting  devices  to  generate  a list  of  actions  to 
perform,"  <*CONFIG-DEFN>  The  LISP  program  SET-UP-CONFIG  which  elaborates  it  is 
not  shown  in  Appendix  2.  CONFIG  is  used  as  an  abbreviation  in  Appendix  3. 

1 1 1 .B.3  Constraints 

(1)  (CONSTRAIN  < -quantities-  > |pred|) 

Executing  this  action  commits  the  interpreter  to  making  pred  hold  true  of 
the  various  physical  quantities  and  control  quantities.  Thus,  it  is  naturally 
a policy.  CONSTRAIN  is  a peculiar  mixture  of  ACHIEVE  and  A'SUME.  If  a 
quantity  is  under  control,  you  are  permitted  to  ASSUME  it  has  any  value  that 
doesn’t  contradict  what  is  already  known  about  it.  So,  when  CONSTRAINing.  it 
is  often  permissible  to  record  any  equalities  deducible  immediately  from  its 
constraint  plus  other  constraints  and  equalities  to  be  found  in  the  data  base. 
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(Cf.  (Sussman  and  Stallman,  13751.)  If  these  constraints  and  egualities 
contradict  the  neu  constraint,  the  action  fails.  (See  Sect.  III.B.) 

In  detail  <*CONSTRAIN-DO>,  this  is  hou  CONSTRAINing  is  done:  if  the  number 
of  unknowns  is  exactly  one,  and  the  main  connective  of  the  constraining 
predicate  is  then  the  system  is  to  try  to  solve  the  eriuation 

immediately.  <*C0NSTRAINT-RES(3LVE-00>  If  it  is  solvable,  the  result  is  to  be 
protected,  (See  below.)  In  either  case,  the  CONSTRAIN  remains  an  established 
policy  (a  "constraint"). 


Algebraic  Symbol  Manipulation 

Several  times  in  discussions  of  constraint  and  equality  manipulation  I 
have  assumed  some  sophisticated  symbo I -man i pu I a t i on  ability  by  the  program. 

The  various  tasks  that  I take  for  granted  include  solving  equations,  choosing 
values  to  satisfy  rather  arbitrary  constraints  (including  inequalities),  ant) 
finding  the  precise  way  that  a one  control  quantity  depenris  on  the  variation 
in  another  (see  Sect.  III.B).  In  the  long  run,  it  would  be  enlightening  to 
see  whether  the  structure  of  the  NASL  system  is  sufficiently  flexible  for  this 
information  to  be  encoded  as  a set  of  NASL  formulas.  Preliminary  inriications 
are  that  this  is  quite  feasible;  very  simple  equations  are  already  solved  by 
the  tasks  generated  by  <*EGN-S0LVE-D0>.  (Other  equations  might  be  handled  by 
the  methods  of  (Bundy,  1375).)  My  judgment  has  been  that  to  explore  this  byway 
in  more  depth  would  bog  me  down.  This  decision  is  not  obvious:  after  all. 
flexibility  of  application  is  one  of  the  main  design  goals  of  my  system. 
However,  having  an  implementation  of  one  domain  is,  for  now.  much  preferable 
to  having  curious  fragments  of  several.  Therefore,  I depend  upon  calls  to  an 
expert  symbo  I -man  i pu  I at  i on  system  to  do  this  work  for  DESl.  1 might  have  used 
some  symbo I -man i pu I at i on  system  like  MACSYMA  (Mathlab,  137A).  but,  for 
simplicity,  I chose  myself  as  this  expert  subsystem.  Uhenever  a non-trivial 
symbo I -man i pu I at i on  problem  needs  solving,  the  system  types  out  a request  for 
a solution  and  waits  for  its  human  interlocutor  to  supply  it. 

It  is  to  be  hoped  that  this  is  not  a permanent  trend  in  computer  science, 
since  it  tends  to  reverse  the  usual  practice  of  having  humans  do  the  creative 
work  while  machines  do  the  tedious  chores. 


A 
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(2)  ISELECT-VALUE  jcontrol  attributel  |pr  i m i t i ve  dev i ce | I 

This  action  is  to  be  postponed  until  all  tasks  of  Types  1,  2 and  A are 
finished.  <*SELECT-POSTPONE>  DESI  makes  all  SELECT-VALUEs  subtasks  of  a task 
SELECT-EM-ALL  uh  ich  is  a successor  of  every  "topology-changing  task."  It  is 
assumed  that  this  kind  of  task  is  recognizable  from  its  action  function. 

(MAKE  and  FIX  (-quantity)  are  the  only  built-in  topology-changers.) 

Uhen  the  system  gets  to  a SELECT-VALUE  task,  either  the  control  attribute 
for  this  device  already  has  a value;  or  DESI  must  pick  a value  uithin  the 
range  of  the  control  attribute  uhich  fits  al!  the  knoun  constraints  on  it 
<*SELECT -VALUE -D0>,  and  impose  model  effect 

[-/>  ’(|control  attributel  Iprimitive  device|)  |value|). 

It  then  PROTECTS  the  fact  that  the  value  satisfies  the  constraints. 

If  there  is  no  such  value,  the  system  is  faced  uith  a "constraint 
collapse"  (see  Sect.  III.B);  that  is,  it  has  made  a mistake. 

Executing  SELECT-VALUE  tasks  causes  the  resolution  of  all  remaining 
constraints  of  a network. 

(3)  (PROTECT  ’ Iproposi t ionl I 

The  intent  of  this  action  is  that  the  system  should  become  alarmed,  i.e., 
realize  it  has  made  a mistake,  uhen  the  fact  is  no  longer  true  in  the  model. 
This  is  not  as  easy  as  it  sounds  or  as  it  is  usually  implemented  (Sussman, 
1975),  because  the  given  fact  may  be  only  indirectly  related  to  atomic  facts. 

Because  data  dependencies  are  maintained  by  the  system,  it  might  lie 
possible  in  principle  to  make  this  a built-in  action.  That  is,  the  system 
could  just  wait  for  propagating  erasures  to  wipe  out  a fact.  Something 
special  would  have  to  be  done  for  the  results  of  non-monotonic  inference  (that 
is,  using  /:CONSISTENTLY) , because  in  this  case  it  is  recording  a fact  that 
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could  upset  the  protected  fact. 

For  this  reason  (and  for  the  weak  introspective  reason  that  protection 
does  not  seem  to  be  a fool-proof  operation),  I have  DESI  treat  protection  as  a 
problematic  action  to  be  reduced  to  different  subtasks  in  different  cases. 

This  decision  is  under  review.  ^ 

In  the  design  domain,  we  have  need  primarily  of  protecting  values  which 
are  derived  from  cons  if||trat  i on  of  constraints.  This  is  done  <iirQVAL-PROIECT> 
by  / : flONI  TOR  i ng  the  fact  that  the  quantity  has  a value  and  /tCONTINUing  the 
protection  policy  when  the  value  is  removed.  <*PR0TECT-C0NT I NUE > 


CPROTECT 

’(SATISFIES  ’(R  R#71)lCl)D 

e. 

o 

(R  R#71) 
Changed 


CPROTECT 

...1 


o 


o 

D:MONITOR 

C=/>  (K  R#71)  SOOkiO 
(x(T) 

(/iCONTINUE 

(PROTECT...)))] 


O ►( 

CVERIFY  / 

’(SATISFIES...)] 

/ 

o 


Re 

C /.MONITOR 


C/.FIND 

new  (R  R#71)] 


Figure  1 1 1.9  Quantity-Value  Protection  Plan  Schema 
Notice  that  the  variable  may  be  getting  a new  value  which  satisfies  the 
constrainte,  so  the  system  cannot  jump  to  the  conclusion  that  a protection 
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violation  has  occurred.  The  decision  to  continue  the  policy  is  generally 
postponed.  Upon  continuing  it,  if  a violation  has  occurred,  DESI  realizes  its 

mistake. 

III.B.4  Changing  Devices 

This  is  a catch-all  category  uhich  includes  biasing,  feedback,  coupling, 
and  fixing  the  value  of  a physical  quantity.  These  actions  are  described  in 
the  next  chapter.  Other  domains  would  have  other  actions. 

The  last  action  in  this  list  is  the  only  one  I feel  there  is  anything  to 
be  said  about  at  the  rarefied  level  of  general  design.  Even  for  that  one, 
about  all  that  can  be  said  is  that,  for  almost  any  domain,  there  exist  ways  of 
fixing  physical  quantities,  bringing  them  under  control,  creating  "boundary 
conditions."  For  electronics,  this  is  done  with  sources,  voltage  dividers, 
etc.  In  mechanical  engineering,  it  might  include  fastening  things  down, 

hooking  up  motors,  etc.  Perhaps  it  is  worth  saying  that  "FIXing  a physical 

t 

j quantity  means  turning  it  Into  a control  quantity,"  but  I’m  not  sure  how  to 

I say  that.  It  is  likely  that  the  way  one’s  knowledge  of  this  sort  of 

i 

regularity  is  used  is  in  assimilating  a new  domain;  namely,  everyone  knows 
that  when  he  is  learning  about  meta-hydrau I i c engineering  he  should  be  sure  to 
ask  what  methods  there  are  for  fixing  meta-hydrau I i c quantities. 

Besides  these  actions,  which  arise  in  the  course  of  normal  problem 
solving,  there  are  actions  (subsumed  under  "patch"  in  Fig.  III.G)  required  to 

I 

change  a circuit  because  it  is  failing  to  meet  its  specifications.  These  are 
described  in  Sect.  III.D;  they  are  not  implemented,  because  the  mistake- 


correction  machinery  to  support  them  does  not  exist. 

Many  design  plan  schemata  are  arranged  in  specialization  hierarchies 
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similar  to  hierarchies  of  specialized  composite  device  types.  (Sect.  I II. A) 
This  is  especially  true  of  the  circuit-alteration  plans  discusserl  in  the  next 
chapter.  The  reason  for  this  is  that  a circuit-alteration  plan  for  an  action 
like  "bias  ..."  is  close  to  being  a device  type.  The  difference  is  that  the 
procedural  component  is  larger  and  the  plan  is  more  anonymous:  the  resistors 
used  for  biasing  do  not  become  components  of  a "biasing  device,"  but  of  the 
circuit  that  is  being  biased. 

Just  as  devices  may  be  related  by  the  predicate  SPEC-DFV-TYPE,  plan 
schemata  may  be  related  by 

(SPEC-SCHEMA  jplan  schema  1|  |plan  schema  2|1. 

Any  instance  of  the  specialized  schema  (1)  is  an  instance  of  the  general 
schema  (2).  <*SPEC-SCHEMA-OEFN>  Choice  rules  are  provided  for  these  plan 
schemata  which  are  completely  analogous  to  the  rules  (Sect.  III.B.2)  for 
choosing  among  specialized  device  types.  <*SPEC-IS-BETTER,  T UO- SPECS -UORSE- 
THAN-ONE> 

Two  other  useful  control  predicates  defined  in  the  file  DESI  are  STASK 
<eSTASK-DEFN>  and  REDUCE.  <*nEDUCE-DEFN>  The  first  is  used  to  abbreviate  in 
the  common  case  where  a task  is  defined,  and  made  a subtask  of  something  else. 
In  the  same  breath.  The  second  is  used  to  express  a common  interaction  among 
design  plans:  when  one  plan  accomplishes  part  of  the  function  of  another.  In 
that  case,  saying  (REDUCE  < -reducers-  > |reducee|)  means  "the  reducer  tasks 
are  all  the  subtasks  of  the  reduces  task:  don’t  bother  to  try  to  execute  it 
any  further."  (Cf.  Sect.  II.B.l.) 
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III.C  Composition  of  Partial  Solutions 

One  of  the  most  interesting  and  complex  events  that  can  happen  during  the 
career  of  any  problem  solver  is  the  failure  of  the  labels  attached  to  its 
canned  plans  to  match  all  of  the  requirements  of  some  task.  In  a design  task, 
this  situation  allous  unlimited  scope  for  the  study  of  creativity.  Of  course, 
our  knowledge  of  such  matters  is  as  yet  very  slight,  so  that  the  approach  my 
system  takes  to  the  handling  of  such  problems  is  not  terribly  brilliant, 

Uhen  a DESIGN  task  does  not  immediately  succeed,  an  attempt  is  made  (Sect, 
I I I .B)  to  break  it  down  into  a core  task  plus  several  constraints  and 
"features."  For  example,  the  knowledge  in  ZORCH  is  sufficient  to  discover 
that  an  amplifier  is  required  given  a wide  range  of  requests  for  designs. 

Then  further  choice  information  from  ZORCH  is  used  to  select  one  that  is 
likely  to  meet  all  the  amplifier  constraints  so  generated.  As  mentioned  in 
Sect.  II. A,  this  sequence  is  called  the  "recognition  protocol."  Finally,  the 
constraints  are  resolved. 

Often  this  approach  fails.  It  may  fail  in  more  than  one  way: 

(1)  (lore  than  one  "core  device-type"  (see  Sect.  I II.  A)  may  be  discovered. 

(2)  There  may  be  more  than  one  way  to  implement  a core  device  type.  (See 
above,  especially  the  discussions  of  "superordinate"  device  classes  anri 
abstract  device-types.) 

(3)  The  constraints  generated  may  not  actually  be  satisfiable. 

All  of  these  problems  may  call  for  composition  of  solutions  to  subproblems. 

The  last  problem  is  peculiar  in  some  ways;  I devote  section  lll.D  to 
describing  constraint  resolution. 

The  others  are  related  by  having  to  do  with  the  choice  protocol.  For 
example,  problem  (2)  may  arise  if  more  than  one  amplifier  fits  some  of  the 
requirements,  and  none  fits  well  enough  to  exclude  the  others.  In  this  case, 
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the  response  of  the  system  uhen  no  further  eKclusions  can  be  marie  is  to  record 
lOUIESCENCE  Ichoice  name  | ) in  the  choice  rlata  pool. 

It  is  here  that  choice  rules  with  conclusions  of  the  form  l/:RIILE- 
T0GETHER...1  are  important.  They  allow  options  to  be  superserled  by  new 
options.  This  is  the  most  natural  and  painless  place  for  composition  to  occur 
In  a NASL-based  system. 

This  is  the  closest  DESI  comes  to  a universal  composition  method.  This  is 
a defect  in  the  system  as  it  exists.  A better  system  would  recognise  the  need 
for  a /: RULE- TOGETHER  and  propose  one;  future  episodes  would  exercise  and 
modify  it.  For  example,  some  of  the  choice  rules  for  amplifiers  discussed  in 
the  next  chapter  contain  almost-general  principles  regarding  cascading  a 
buffer  amplifier  to  another  amplifier  when  the  first  was  picked  for  its  input 
impedance.  It  is  not  hard  to  see  a more  general  principle  regarding  inputs 
and  outputs  lurking  behind  this  specific  one.  It  lurks  there  still. 

For  now,  you  must  be  content  with  the  specialized  composition  rules  in 
Chapter  IV. 

III.O  Constraint  Collapse 

As  a design  proceeds,  the  current  data  pool  fills  up  with  formulas 
specifying  components,  connections,  quantity  values,  and  constraints.  If 
everything  proceeds  smoothly,  eventually  there  will  be  a value  for  every 
primitive  component  and  the  problem  will  be  solved.  The  most  common  thing  to 
go  wrong  with  this  scenario  is  to  discover  that  some  subset  of  constraints 
cannot  be  satisfied.  DESI  counts  this  as  a mistake  in  the  setise  of  Sect. 

II.E,  All  its  previous  machinations  were  based  on  the  assumption  that  the 
functional  requirements  could  be  reduced  to  constraints  and  satisfied.  Uhen 
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this  turns  out  not  to  be  the  case,  the  task  netuork  must  be  altered  to  reflect 
what  it  should  have  been  doing.  On  the  other  hand,  as  much  as  possible  of  the 
network  must  be  salvaged. 

As  I pointed  out  in  Sect.  lI.E.  my  theory  of  mistakes  is  as  yet  poorly 
developed.  This  section  must  be  taken  as  a continuation  of  the  detailed 
proposal  I made  there,  not  as  a description  of  existing  program. 

As  a concrete  example,  say  that  a low-pass  filter  is  required,  which 
filters  out  one  radio  station  at  700tCHz  to  leave  the  signal  of  another, 
equally  strong  station  at  500kHz. 


KEEP  FLUSH 

I A 

500  700 

Figure  1 1 1.10  Radio  Spectrum  With  Two  Stations 
This  problem  can  be  represented  easily  using  the  "frequency  picture"  language 
1 will  develop  in  Chapter  IV.  I will  continue  to  use  simple  English  in  what 
fol I ows. 

The  chosen  solution  is  an  RC  low-pass  filter,  an  instance  of  the  schema 


represented  by  Fig.  I.B.  This  schema  and  the  frequency-domain  methods  used  to 
find  it  (Sect  IV.B.l)  generate  these  constraints  and  equalities: 
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CONI  (from  rephrasing  of  the  problem): 

Vjj(700  kHz)  < .IV^ (500kHz) 

C0N2  (from  schema  for  RC  filter  or  by  analysis): 

H(s)  - ^ 

1-HRCs 


C0N3  (from  knouledge  of  filters): 
selectivi  tytfp  f2)  - 

|H(j2nr2l 


C0N4  (from  knouledge  of  linear  devices): 

|H(j2nD  I - 

v^(n 

Figure  III. 11  Relevant  Constraints 

From  these  constraints  and  the  statement  of  the  problem,  ue  can  build  up 


the  follouing  "constraint  network": 
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C0N2(fl) 


CON2(f2) 


C0N4(fl) 


Figure  111.12  Constraint  Network 
(Cf.  <«CQ-CLO>  in  Appendix  2.) 

If  all  the  constraints  are  satisfiable,  that  is,  if  the  output  amplitude 
ratio  can  be  made  small  enough  that  the  second  station  has  negligible  output 
compared  to  the  first,  everything  is  fine.  But,  as  it  happens,  there  are  no 
values  of  R and  C which  can  be  picked  in  order  to  bring  this  off.  This  is 
referred  to  as  "constraint  collapse."  This  will  be  noticed  when  one  of  the 
constraints  proves  unsat  i sf  iable.  Uhich  constraint  it  will  be  is 
unpredictable;  the  problem  is  clearly  a problem  of  the  whole  network  rather 
than  any  task. 

Recall  from  Sect.  II. E that  fixing  a mistake  Involves  altering  the  current 


a 
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uor  I d model  and  the  task  network.  In  this  case,  there  are  several  current 
tasks  that  have  caused  the  problem:  the  choice  of  an  RC  circuit  to  implement 
the  low-pass  filter,  and  the  various  CONSTRAINS,  some  thauerl  from  the  RC 
schema,  which  led  to  the  trouble.  DESI  has  a record  of  every  choice  it  made 
in  the  process  of  setting  this  network  up.  so  it  could  find  a choice  point 
that  would  make  a difference,  restore  the  state  of  the  world  at  that  point, 
and  try  something  else;  I have  already  discussed  and  rejected  this  in  Chapter 
II. 


The  design  knowledge  of  DESI  provides  us  with  a better  method  of  solving 
this  problem.  This  method  amounts  to  the  following  English  summary: 

(1)  Find  a control -quant i ty  in  the  collapsed  task  network  such  that 
changing  it  would  get  rid  of  the  problem.  This  is  not  as  easy  as  it  sounds. 

It  is  counterproductive  to  consider  "making  V0(500kHz)  larger."  for  instance. 
Any  method  for  doing  that  will  probably  make  V0(700kHz)  larger  as  well.  In 
the  example,  the  proper  answer  is  "selectvi ty. " I assume  symbol  manipulation 
powerful  enough  to  handle  this.  (Sect.  I II. 0.3) 

(2)  Introduce  a new  task  (IflPROVE  '[losing  control  quant ity|  [direction 
and  magnitude[).  A task  of  type  IMPROVE,  unlike  previous  contro I -quant i ty 
manipulators,  has  the  aim  of  changing  some  already-set  object  rather  than 
fixing  one  that  has  yet  to  be  set.  To  execute  the  IMPROVE  task  requires  some 
domain-dependent  rephrasing,  choice,  etc.,  which  by  now  are  routine.  By  one 
route  or  another,  a plan  like  that  of  Fig,  1.7  is  recovered. 

(31  The  actual  tasks  associated  with  the  IMPROVE  plan  perform  the 
acquisition  and  insertion  of  the  new  pieces,  an  amplifier,  capacitor,  and 
resistor,  and  the  renaming  of  the  output  port.  The  resulting  change  in 
topology  flushes  the  old  constraints  on  (he  system  function  and  hence  the 
selectivity  of  the  device  and  enables  the  design  to  be  completed.  This  is  not 
too  painful,  since  the  control-quantity  ( (H  ?OEV)  ?F)  is  marked  DENERIC-CA  in 
the  data  pool;  when  the  old  stored  value  is  flushed,  a task  is  enqueued  to 
recalculate  it. 

Except  for  the  initial  symbol  manipulation,  this  seems  fairly  simple;  the 
IMPROVE  task  is  no  different  from  any  other  task,  such  as  BIAS  or  COUPLE, 
which  alters  the  topology  and  part  names  of  a circuit.  The  difference,  of 
course,  is  that  the  policies  associated  with  the  IMPROVE  plan  must  specify 
exactly  what  parts  of  the  old  task  network  encircling  the  RC  filter  are  to  be 
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preserved.  The  difficulty  of  implementing  this  scheme  revolve  around  the 
careful  undoing  of  protections  and  other  policies. 

III.E  Programmer’s  Guide 

DESI  is  a skeletal  theory  of  design  uithin  which  the  user’s  domain- 
dependent  rules  operate.  These  rules  will  fall  into  three  classes:  rephrasing 
rules,  device  definitions,  and  device-choice  rules. 

The  user’s  rephrasing  rules  can  be  very  simple.  Any  declaration  that  a 
function  is  a CONTROL-ATTRIBUTE  will  cause  the  cq-shard  machinery  to  turn  a d- 
shard  of  the  form  t (X  (X)  (-  ((attribute!  ?X)  |value|)]]  into  a side-task  to 
CONSTRAIN  the  given  control  quantity. 

Hore  complicated  rules  can  create  entire  inferential  subtasks  to  make 
finer  discriminations.  Examples  will  be  given  in  the  next  chapter. 

In  making  up  device  schemata,  the  user  will  have  to  use  his  intuitions. 
Superordinate  device  types  are  convenient  slots  to  put  inheritable 
characteristics  into.  A basic  device  type  is  one  with  a "diagram"  common  to 
every  member  of  the  type.  (I  assume  that  every  domain  DESI  is  likely  to  be 
applied  to  will  have  the  concept  of  diagram.)  The  "diagram"  (device  schema) 
will  not  be  attached  to  the  basic  device  type  directly:  instead,  each  node  in 

the  DERIVED  tree  below  the  basic  type  (see  Fig.  1 1 1. 5)  will  have  its  own 
schema.  (Remember  that  the  details  of  the  diagrams  for  a device  type  and  one 
of  its  specializations  are  likely  to  be  inconsi stent;  the  task  networks  of  the 
two  will  be  related  via  the  SDUL  device.) 

In  writing  choice  rules,  the  user  has  a certain  amount  of  freedom.  There 
are  three  stages  in  picking  a device  type  or  design  plan:  deducing 
possibilities,  running  choice  rules  before  (XJIESCENCE,  and  running  choice 


Ill  Design  of  Hierarchical  Systems 


127 


rules  after  QUIESCENCE.  (See  Sect.  II.C.l.)  There  Is  as  yet  no  iron-clad 
semantics  for  uhat  each  of  these  stages  means,  mainly  because  I lack 
experience  in  interfacing  rules. 

Typically,  the  "possibility”  rules  are  very  lax;  if  a device  could  be 
appropriate,  given  some  piece  of  the  current  situation,  some  rule  should 
suggest  it.  Throuing  it  auay  or  incorporating  it  into  a larger  structure  is 
the  job  of  the  choice  rules.  (Cf.  CHIDOSE-AflP,  in  Appendix  3,  descrlbetl  In  the 
next  chapter. ) 

The  user  should  be  careful  in  his  use  of  /:RULE-0UTs  if  this  is  the 
structure  he  chooses.  If  there  are  two  relevant  variables  in  a situation,  and 
one  is,  strictly  speaking,  incompatible  with  a suggested  device  or  plan,  this 
is  not  necessarily  a reason  to  rule  it  out.  After  all,  it  would  not  be  a 
living  option  in  the  choice  protocol  if  the  other  variable  had  not  caused  it 
to  be  suggested.  For  example,  i nput- i mpedance  considerations  may  suggest  a 
common-collector  amplifier,  while  gain  considerations  suggest  something  else. 
It  is  clearly  silly  to  throw  away  the  common-collector  suggestion  on  the  basis 
of  gain.  Instead,  a /: RULE- TOGETHER  is  probably  appropriate. 

/:RULE-0UTs  are  useful  mainly  as  a device  for  expressing  "differential 
diagnosis*  information.  Such  a rule  mentions  two  or  more  options,  and  throws 
one  of  them  away.  Remember  that  the  order  of  examination  of  these  predicates 
is  /:RIA-E-0UT,  then  /:RULE-IN,  then  /:RULE-TOGETHER,  and  that  the  choice 
protocol  quits  as  soon  as  fewer  than  two  options  remain. 

QUIESCENCE  has  no  fixed  meaning.  Sometimes  the  system  uses  it  to  express 
rules  which  are  intended  to  take  over  if  the  user’s  rules  can’t  make  up  their 
minds;  this  is  the  case  with  the  rules  for  choosing  among  SPEC-DEV-TYPEs. 

(Sect.  III.B.2.)  This  freedom  probably  represents  a deficiency  in  the  choice 
mach i nery. 
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IV  Electronics 

Electronics  knowledge  falls  naturally  into  three  categories;  the  physics 
and  mathematics  of  electronic  components,  devices,  and  signals;  the  knowledge 
necessary  to  do  design,  including  rephrasing,  composition,  and  patching:  and  a 
catalogue  of  circuit  diagrams  and  plans. 

In  this  chapter  as  in  the  last,  the  notation  <*rormula-name>  is  a 
reference  to  a formula  in  the  appendices,  in  this  case  usually  Appendix  3. 

This  Appendix  is  rather  long,  but  has  been  laid  out  in  an  order  which 
corresponds  as  closely  as  possible  with  the  presentation  of  this  chapter. 

This  chapter  is  fairly  dull.  Given  the  vocabulary  and  conventions  developed 
in  Chapter  III,  it  is  routine  to  encode  much  of  the  information  I will 
descr ibe. 

Appendix  3,  long  as  it  is,  can  only  be  described  as  "sketchy."  For  each 
important  concept  I will  discuss,  there  is  a representative  circuit,  plan,  or 
rule  set  in  the  appendix,  but  often  several  of  its  siblings  will  he  missing. 

I will  describe  these  gaps  in  Sect.  IV. D. 

IV. A Physics 

IV.A.l  Connections  and  Constraints  on  Components 

Recall  from  Chapter  III  that  connections  in  a design  domain  are  physical 
configurations  associated  with  constraints.  In  electronics,  these 
configurations  are  called  nodes. 


Interfaces  between  electronic  devices  are  of  two  types;  terminals  and 
ports.  I will  discuss  ports  later.  A terminal  is  a wire  coming  out  of  a 
primitive  or  composite  device.  A group  of  terminals  may  be  bunched  into  a 


I 
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"node."  One  constraint  on  a node  is  "Kirchhoff’s  Current  Law"  (KCL)  (Senturia 
and  Uedlock,  1975),  which  says  that  the  sum  of  the  currents  into  a physical 
node  is  zero.  My  "logical"  nodes  are  treated  as  terminals  themselves  at  a 
"higher  level,"  where  they  may  themselves  he  joined  into  nodes.  <^NOOI - IRM I N> 
(See  Fig.  IV. 1).)  KCL  for  nodes  therefore  states  that  the  current  into  the 
node,  considered  as  a terminal,  eguals  the  sum  of  the  currents  out  of  the  sub- 
terminals  defining  the  node.  <*KCL-2> 


Figure  IV, 1 Terminals  and  Nodes 


Devices  also  satisfy  Kirchhoff's  Current  Law.  <*KCL-1>  A composite  device's 
terminals  are  almost  always  nodes  themselves.  These  will  be  declared  with  the 
predicate  OEV-TERtll NALS.  <*ICCL-3>  (Fig,  IV. 21 


d. 


V 
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(dev-terminals  D* 

< (N1  D-)(n2  D-): 


Figure  IV. 2 Composite  Device  Terminals 
A fundamental  model  manipulation  in  the  electronics  domain  is  to  merge  two 
nodes,  which  makes  them  equal.  <*NODES-riERGE-nANlP>  A less  easily  visualized 
operation  is  DEV-INSERT  <*DEV-INSERT-f1ANIP>.  which  breaks  a node  in  two. 

(Fig.  IV. 3) 


T3 

I D"  ^#2 


(DEV-INSERT  D"  N 
<(#1  D’)xT2  T3  T4> 
<(#3  D-)*<  T1  T5>) 


#3 


Figure  IV. 3 Inserting  a Device  into  a Node 
Ports  are  pairs  of  terminals  (which  are  almost  always  nodes  of  composite 
devices),  to  be  thought  of  as  carrying  signals.  The  signals  may  be 
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implemented  either  as  currents  or  voltages.  <*P0RT-TAX0N0t1Y>  A set  of  voltage 
ports  may  he  grouped  Into  a nest,  uhich  is  exactly  analogous  to  a node  formed 
by  grouping  terminals.  (In  particular,  every  nest  Is  considered  a higtier- 
I eve  I port.)  <*NEST-i^nT>  Ports  may  be  combined  into  nests,  and  nests  may  be 
merged,  just  as  terminals  are  combined  into  nodes.  <*NESTS-MERGE-nANlP> 

Nest 


Port 


port  2^ 


port  3 


(b) 

Figure  IV. 4 Ports  and  Nests 


Kirchhoff  also  had  a voltage  lau,  uhich  for  our  purposes  merely  amounts  to 
the  fact  that  every  point  in  space  can  be  assigned  a conventional  voltage.  To 
enforce  this,  the  rule  <*KVL-1>  constrains  all  the  node  and  terminal  voltages 
at  a physical  node  to  be  the  same. 

All  devices  are  given  interface  descriptions  by  the  packets  defining  their 
device  types.  The  interface  description  (e.g.,  "?X  is  a 2- term i na I " ) interact 
Mith  formulations  of  Xirchhoff's  voltage  and  current  laus  to  generate  standard 
constraints.  <*2-TERf1INAL-0EFN>  Composite  device  types  (see  Chapter  III)  may 
have  terminal  or  port  interfaces,  or  both. 

An  important  class  of  devices  are  the  "signal  tr ansmogr i f i er s"  or  SIG- 
TRANSERS,  by  uhich  I mean  any  device  one  of  uhose  primary  functions  is  to  take 
a signal  in  on  its  input  port,  or  "INPORT,"  and  put  out  3 signal  on  its  output 


port,  or  "OUTPORT."  <*SIG-TRANSER-GLORI A-t1UN0l > 
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(Much  of  the  notation  In  this  and  the  follouing  sect  Ion  has  been 
influenced  by  the  notations  devised  by  A.  Broun  (197S)  and  Stallman  and 
Sussman  (19761 . ) 

I V . A . 2 Si gna I s 

Signals  are  abstract  objects  uith  three  components:  a time  function,  a 
8 i gna I -med i urn  (voltage  or  current),  and  a "home”  (a  port).  "A  signal  is  any 
physical  variable  whose  magnitude  or  variation  with  time  contains 
Inrormation. , , . Uhen  we  speak  of  ‘signals,’...  we  refer  ...  to  voltages  and 
currents."  (Senturia  and  Uedlock,  1975,  p.2) 

A "homeless"  signal  is  no*  allowed  In  my  notation.  A signal  may  have  more 
than  one  home,  but  only  if  all  its  homes  are  in  the  same  nest.  <*KVL-2> 

Given  a port,  the  function  PORT-SIGNAL  should  give  its  signal. 

To  make  up  for  the  absence  of  homeless  signals,  many  actions  manipulate 
signal  descriptions,  lambda-expressions  from  signals  to  truth  values.  For 
example,  the  formula 

(CONVERT  |device|  (signal  description!  (signal  relation(l 
means  "device  converts  any  signal  appearing  on  its  INPORT  which  satisfies  the 
description  into  an  OIJTPIJRT  signal  which  bears  the  relation  to  the  input 
signal."  An  example  of  the  use  of  this  predicate  appears  in  Chapter  I. 


Another  is. 
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[DESIGN  (X  (HI 

(CONVERT  TX 
(X  (SI  I 
(FORALL  (F) 

(IMPLIES  (/>  ?F  IMHz) 

(-  ( (FOLIRIER-TRNSFRM  (TFUN  ?S1))  ?F) 
0)11  I 

(X  (SI  S2I 
(FORAIL  (F) 

(ANO  (IMPLIES  (/<  ?F  100kHz) 

(-  ((FOURIER-TRNSFRM  (TFUN  ?S2I) 
?F) 

01 1 

(IMPLIES  (/>  ?F  100kHz) 

(-  ((FOURIER-TRNSFRM  (TFUN  ?S2)) 
?F) 

((FOURIER-TRNSFRM  (TFUN  ?S1 ) ) 
?F)))))  )))I 


This  formula  illustrates  the  use  of  the  Fourier  transform  of  a signal. 

The  DESI+ZORCH  system  actually  lacks  any  deep  mathematical  understancling 
of  transforms.  Instead,  it  summarizes  the  frequency-domain  behavior  of  a 
signal  uith  a frequency  picture  of  its  time  function.  A frequency-picture  is 
a tuple  of  "frequency  features."  A feature  is  specified  as  (FF  |freq| 

I landmark!).  <*FF-FREQ,  FF-LANDMARK>  A landmark  may  have  a shape,  height,  and 
width,  written  FL-SHAPE,  FL-HEIGHT,  or  FL-UIDTH.  In  general  any  particular 
characteristic  is  optional,  but  the  assumption  is  that  a feature  has  non-zero 
size.  These  are  similar  to  the  human  conventions  for  such  descriptions. 

Sigr'al  characteristics  can  have  these  values: 

shape  --  may  he  SPIICE,  HUMP 

UIDTH  --  a HUMP  may  be  SHARP  or  FUZZY 

HEIGHT  --  a number 

The  notation  (SERIES  |(req|  jdelta  freqj  jshapej  jfunjl  defines  an 
infinite  frequency  picture  consisting  of  a row  of  features  of  the  given  shape, 
at  interval  of  delta  freq,  starting  at  the  given  frequency.  The  height  of  the 
nth  landmark  in  the  row  is  given  by  fun.  This  function  must  he  decreasing  (as 
it  will  be  in  all  physical  applications). 
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(This  uay  of  reasoning  about  the  frequency  domain  is  in  many  Mays  closer 
than  straight  Fourier  transforms  to  the  uay  humans  think  about  it,  and  reveals 
more  about  the  signals.  This  is  a good  illustration  of  the  point  that  using  a 
logical  notation  does  not  commit  you  to  a "mathematical"  treatment  of  a 
doma i n. ) 

For  example,  a square  uave  of  frequency  f offset  by  half  its  amplitude  4 

has  frequency  picture  picture 

[<IFF  0Hz  LANOMARk«79) 

'»(3ERIES  in  :*  2 |f|) 

SPlIfE  (X  (N)  (*  |4|  (//  4 l»  ?N  Pim  ))>] 

where 

(FL -SHAPE  L AN0nARI«f79  SPIKEl 
and  (-/>  '(FF-ICIGHT  LAN0nARK<f79)  (//  |4|  2)). 

The  usual  graphical  notation  for  the  Fourier  transform  of  an  offset  square 

wave  is,  of  course, 


Figure  IV. 5 Fourier  Transform  of  an  Offset  Square  Uave 
Time-domain  signal  attributes  are  also  known  to  the  system.  A function 
may  be  par  iodic  with  a certain  period,  expressed  as  IPERIOOIC  |tfun| 

|period|l.  If  so.  lONE-PFRIOO  |tfun|l  is  a function  which  is  zero  everywhere 
except  from  -T/2  to  T/2.  where  MONE-PERIOO  |tfun|)  ?TI  - I|tfun|  ?T) . (T  is 
the  period  of  the  function.)  Others  are  (following  (A.  Broun,  19751)  the  DC 
offset  of  the  signal;  amplitude,  the  height  of  a periodic  signal;  phase  with 
respect  to  another  signal;  etc. 
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A large  set  of  formulas  is  concerned  uith  computing  the  frequency  picture 
of  periodic  signal  descriptions  expressed  in  time-domain  terms.  <*PERI0DIC- 
FREQ-PIC> 

Besides  these  intrinsic  descriptions,  there  are  "extrinsic"  signal 
properties  like  "carrier,"  or  "modulation,"  or  "distortion,"  These  concepts 
would  be  necessary  for  a system  that  designed  or  redesigned  radios,  wh'ch  are 
a level  above  that  which  I have  focused  on,  (This  is  the  chief  difference  in 
e>mphasis  between  Brown's  approach  to  signal  description  and  mine.)  It  appears 
to  me  that  it  would  be  easy  and  instructive  to  add  this  knowledge  to  OESI  , but 
that  it  would  be  a slight  detour. 

Of  course,  the  descriptions  of  Signals  are  of  interest  only  so  far  as  they 
suppor t compar i son.  Ue  are  interested  in  designing  circuits  which  conver t 
from  one  kind  of  signal  to  another;  given  two  pictures,  a good  description  of 
the  transformation  from  one  to  the  other  will  help  ue  to  retrieve  useful 
plans.  This  will  be  described  below,  in  Sect.  IV. B. 

IV. A. 3 Multiple  Models  of  Linear  Systems 

A great  advantage  of  a I inear  domain  such  as  elementary  electrical 
engineering  is  that  it  may  be  profitably  attacked  by  linear,  t i me- i ndependent 
methods  in  many  cases.  In  addition,  the  fact  that  analysis  is  of  a closed 
network  makes  a forward-deduction  scheme  practical,  (Cf.  (Nevins,  1974c,  and 
Sussman  and  Stallman,  1975).) 

The  folowing  types  of  quantities  are  to  be  dealt  with  by  an  electronics 
analyzer  (see  Sect.  IV. C): 

physical  quantities  like  voltages  and  currents 

component  control  quantities  like  resistances  and  capacitances 
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The  kinds  of  questions  to  be  answered  are: 

Uhat  is  the  the  value  of  some  physical  quantity  in  a given  circuit? 

Uhat  are  the  values  of  derived  control  quantities  like  the  Thevenin 
resistance  or  gain  of  a circuit? 

Often  these  questions  are  with  respect  to  a circuit  of  interest  as  given, 
but  just  as  often  explicit  or  implicit  reference  is  made  to  a derived  model  of 
a circuit.  For  example. 

The  DC  gain  of  a circuit  is  the  gain  of  the  DC  model  of  that  circuit 

The  Thevenin  resistance  of  a circuit  is  the  resistance  of  the  circuit  when 
it  is  disconnected  from  its  environment  and  its  independent  sources  are  set  to 
zero. 

The  impedance  of  a circuit  is  its  (complex)  resistance  in  its  "sinusoidal 
steady  state"  model. 

' etc. 

These  models  are  generated  by  the  use  of  FRAME,  N,  and  T formulas  (see 
Sect.  II.B.2)  in  the  data  base.  Many  of  these  appear  in  the  schemata  for  ^ 

various  devices,  but  the  FRAME  axioms  occur  separately.  Together  they  define 
the  models  as  follows: 

I (1)  ((DC))  The  DC  model  of  a circuit  is  the  same  circuit  with  all  frequency- 

1, ■ dependent  features  nulled  in  a device-dependent  way.  Thus  we  have  <*FRAME-DC> 

I plus  formulas  like 

s 

. (inPLIES  (IS  CAPACITOR  ?X) 

I (AND  (N  (DC)  • (IS  CAPACITOR  ?>()) 

'(  (T  (DC)  (IS  OPEN  ?)()))1 

i 

! (cf.  <*CAP-PKT>)  for  frequency-dependent  components  like  capacitors.  The  (DC) 

I of  an  already-DC  model  is  itself,  because  these  components  can  be  nulled  only 

once.  <*DC-1DEM>  Thus  (see  Chapter  II),  we  have 

(N  (DC)  *(T  ?R  (FRAME  (DC)  <(HErC)>))) 

IT  (DC)  (-/>  ’(DC)  (HERE))) 


(2)  ((INC))  The  incremental  model  of  a circuit.  <*REF-INC,  FRAME-INC,  INC- 
IDEM> 
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(3t  [SSS  |s|)  The  T i nu9o  i fla  I -3 1 eacly-3 1 a t e model  for  complex  frequency  3. 
<*REF-SSS,  555-IDEM,  FRAME-55S>  (In  this  model,  all  linear  devicee  act  like 
resistors  uith  complex  resistances  or  impedances.) 


(A)  (I5DLATE  Itrmin  1|  |trmin  2|)  The  model  obtained  by  disconnecting  the 
given  terminals  from  whatever  nodes  they  appear  in.  <*1S0LATE-0EEN-1 , 2.  and 
3>  (These  terminals  are  usually  nodes  In  a composite  device.)  it  is  used  tor 
calculating  Thevenin  resistances.  <*REF-ISO,  FRAME-150,  IS0-IDEM> 


(5)  (PASSIVE)  The  network  with  all  active  sources  set  to  zero.  Also  used  for 
calculating  equivalents.  <*REF-PASSI VE.  FRAME -PASSIVE,  PASS! VE-IDEM> 


IV, 0 Electronic  Design  Knowledge 

The  knowledge  in  ZORCH  is  meant  to  mesh  with  the  knowledge  in  DESI  so  as 
to  bring  about  useful  behavior.  Generally  DESI  provides  the  plan  framework 
and  some  quite  general  heuristics,  while  the  solid  stuff  is  in  ZORCH.  This  is 
true  of  knowledge  about  design  actions. 

IV.B.l  Rephrasing  Electronic  Design  Problems 

Uhen  it  comes  to  rephrasing  design,  DESI  does  little  more  than  provide  the 
concept  of  "d-shard"  and  the  policy  that  every  shard  in  the  initial  explosion 
must  lead  to  something  useful.  (Chapter  III)  Most  of  the  knowledge  is  in 
ZPRCH.  Here  are  defined  the  interesting  control  quantities  of  this  domain: 
voltage  gain  <*V-GAIN-5HARD>,  and  input  and  output  impedance  <*1NPUT-Z-SHAR0, 
0UTPUT-Z-5HARD> . These  lead  to  side-tasks  which  constrain  control  quantities 
(vfa  <*CQ-SHARD>  in  DESI),  but  they  also  lead  to  domain-dependent  "d- features" 
regarding  the  ranges  of  these  quantities.  These  all  end  up  affecting  the  way 
in  which  device  schemata  are  selected. 

Besides  this  sort  of  control -value  redescr ipt ion,  more  devious  things  can 
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happen.  If  a d-shard  of  the  form  [(X  (|vl>  (CONVERT  ...)J1  appears  in  the 
middle  of  the  explosion,  if  causes  an  inferential  subtask  to  appear.  <*CVT- 
EXPLOOE>  This  subtask  mimics  the  super  task  for  exploding  design  properties,  in 
that,  it  manipulates  formulas  describing  signals,  breaking  them  into  "signal 
shards."  These  signal  shards  are  then  parsed  into  d-shards  and  ultimately 
into  d-features,  side-tasks,  and  core  device  types. 

There  are  tuo  complementary  paths  this  deduction  can  take.  One  <»FREQ- 
D0T1-REPHRASE>  tries  to  compute  the  frequency  pictures  of  the  input  and  output, 
then  find  a transformation  ("FREQ-PIC-TRANS")  between  them.  The  output  of 
this  deduction  is  an  object  of  the  form  [LOU-PASS  |cutoff|),  [HIGH-PASS 
|cutoff|],  [HOOULATE  [freqll,  etc.  This  transformation  becomes  a signal 
shard.  This  language  for  describing  frequency  transformations  is  not  as 
general  as  it  could  be.  On  the  other  hand,  it  is  quite  extensible,  and 
reflects  everything  1 know  about  the  subject. 

The  other  rephrasing  method  <*TIME-00t1AIN-REPHRASE>  merely  searches  for 
certain  simple  functional  relationships  between  the  time  values  of  the  input 
and  output.  (This  has  not  been  implemented  yet.) 

The  system  tries  to  choose  <*CVT-CHOICE>  between  these  two  ways  of 
rephrasing  on  the  basis  of  simple  criteria.  For  example,  if  the  input 
predicate  to  CONVERT  doesn't  mention  the  input  at  all,  the  transformation  is 
more  likely  to  be  a function  of  signal  values,  so  the  time-domain  is  ruled  in, 

IV.B.2  Reconciling  Partial  Solutions 

This  kind  of  infornation  arises  in  tuo  places:  generating  and  choosing 
core  dev i ce- types,  and  choosing  ways  of  making  devices,  (As  in  Sect.  III.O,  I 
am  not  including  information  about  patching  failing  constraints.) 
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It  I9  important  to  note  that  computation  regarding  a circuit  is  to  be 
postponed  whenever  possible  until  after  the  design  rephrasing  plan.  This  is 
because  (a)  the  ideological  intent  is  for  this  phase  to  be  concerned  with 
problem,  not  solutfon,  manipulation;  and  (b)  the  pieces  of  problem  are  lying 
around  in  the  wrong  form  to  be  noticed  during  deductions. 

So,  during  the  d-evploslon  and  subsequent  re-parsing,  DESI  is  more 
interested  in  seeing  the  pieces  than  putting  them  together.  This  orientation 
means  that  ordinarily  the  generation  of  two  core  device-types  is  an  error;  the 
error  will  be  revealed  by  the  choice  protocol  for  the  CORE-FINDER  step  of  Fig. 
III. 7. 

ZORCH  makes  up  for  this  by  allowing  the  design  rephraser  to  pass  the  tjuck 
under  certain  circumstances.  < 1 NEAR- CROUP  1NG>  If  one  of  the  competing  core 
device  types  is  linear,  ZORCH  rules  them  together  into  the  artificial  device- 
type [GROUP  r -device  types-  >1.  GROUP  1 ng  means  CASCADing  in  some  as  yet 
undetermined  order.  ^»r:Al<E-GROUP-l . MAKE-GROUP-Z,  nAKE-GR0UP-3>  The  Idea  is 
to  postpone  deci'Jing  among  them  or  composing  them  until  the  constraints  and 
features  have  been  sorted  out.  After  all,  you  can  be  pretty  sure  a linear 
device  will  not  interfere  too  badly  with  what  it  is  connected  to. 

("Cascading"  two  device-types  means  making  one  of  each  and  coupling  them.  See 
below. ) 

This  is  the  somewhat  bedraggled  method  by  which  core-device-type  choice 
can  give  rise  .tg  cascades.  This  should  be  a rare  event.  Normally,  the  device 
classes  introduced  do  their  job  harmoniously  enough  so  that  one  euperordinate 
or  basic  category  is  natural  for  describing  a desired  circuit.  In  that  case, 
the  category  will  wind  up  as  part  of  the  central  (TAKE  task  of  a design 
network.  (See  Fig.  1 1 1.8. 1 Here  cascading  will  reappear  in  a much  more 
disciplined  way  as  the  choice  of  which  subordinate  or  specialized  device  type 
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to  use. 

In  choosing  a way  to  flAICE  a known  circuit  type  such  as  an  amtilifier,  often 
more  than  one  suggested  subtype  comes  to  mind.  This  will  be  because  various 
subtypes  are  indexed  by  associated  d-NOTES.  <»H0D-V-GAIN,  HIGH-V-GAIN,  etc.> 
If  more  than  one  device  is  triggered  by  a constellation  of  O-NOTES,  it  may  be 
for  two  standard  reasons.  Pirst,  a control  quantity  like  gain  may  fall  into 
two  ranges.  (<*V-GA1N-SHARD>  and  its  ilk  specify  overlapping  ranges,  for 
example.)  If  so.  a value  falling  in  the  ambiguous  region  may  necessitate 
differential  diagnosis  in  the  subsequent  choice  situation.  One  might  have  to 
decide  between  an  op-amp  or  common-emitter  amplifier  on  the  basis  of  cost, 
convenience,  etc. 

Second,  the  two  suggestions  may  answer  to  different  subrequirements,  in 
which  case  they  must  be  combined  in  some  way  (or  one  subrequirement  mtist  be 
foregone) . 

Rules  for  performing  these  functions  for  the  device  type  AMPLIFIER  are 
given  in  the  packets  defined  by  <*CHOOSE-AMP>.  This  contains  principles  like, 
"If  high  bandwidth  is  required,  prefer  a multi-stage  amplifier  to  a single 
high-gain  stage";  and,  "If  one  option  (e.g. , a common-collector)  has  been 
proposed  because  of  its  input  impedance,  and  another  for  some  other  reason, 
cascade  them  in  that  order." 

The  fact  that  in  using  the  rules  of  <*CH00SE-AMP>  the  system  is  restricted 
to  a well-defined  situation  helps  to  make  those  rules  concise  and  to  the 
point.  This  attests  to  the  organizing  power  of  the  concept  of  "superordinate 
device  type."  It  is  difficult  to  think  of  a natural  choice  situation  in  which 
the  statement  of  the  problem  does  not  bring  to  mind  a set  of  rules  organired 
around  some  such  type.  It  appears  that  a large  part  of  the  training  of 
technicians  and  engineers  is  the  accumulation  of  these  sets. 
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Cascading  fun  device  types  is  NAKE-ing  an  object  of  the  abstract  type 
[CASCADE  I type  I(  (type  2().  <»MAI^E -CASCADE  > This  consists  of  a 
straightforward  plan  to  MAKE  a device  of  each  type  and  COUPLE  them.  The 
components  of  the  result  are  the  two  devices.  In  cascading  two  device  types, 
it  is  wise  <*rOUPl  E -GENERAL- 1 , COUPLE -GENERAL-2>  to  use  the  most  general 
specializations  of  the  device  types  involved.  These  are  defined  by  the 
predicate  MOST -GENERAL -SPEC  (defined  in  Appendix  2).  An  example  is  the  device 
type  GENERAL-CE,  which  is  the  most  general  common-emitter  circuit. 

Coupling  comes  under  the  heading  of  a circuit-change  operation.  (Cf. 

Sect.  II1.B.4) 

IV.B.3  Changing  Circuits 

Except  in  the  dullest  circumstances,  a circuit  schema  cannot  be 
instantiated  merely  by  binding  a few  variables.  After  it  has  been  plugged  in, 
its  "expansion  obligations"  become  active.  (In  the  case  of  a productive 
"device  type"  like  ICASCAOE  ...1,  these  obligations  are  part  of  the  plan  that 
makes  a device  of  that  type.)  These  expansion  obligations  are  the  normal 
place  in  which  circuit-changing  tasks  arise.  (If  failure-correction  were 
implemented,  this  would  also  be  a common  source  of  circuit  changes,  of 
cour  se. ) 

The  circuit-changing  actions  defined  so  far  include  biasing,  coupling,  and 
fixing  voltages.  These  actions  come  in  specialization  hierarchies,  and  they 
interact  in  interesting  ways. 

Biasing  bipolar  junction  transistors  (BJTs)  is  defined  by  <*BJT-BI AS-NET> 
as  three  important  tasks:  fixing  the  collector  current  Uq),  reverse-biasing 
the  CO  I I ec  tor -base  junction,  and  fixing  the  base-emitter  voltage  f'or  a 
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typical  one-stage  transistor  amplifier,  these  tasks  are  subsumed  by  the 
specific  suggestions  in  <*TYPICAL-BJT-ONE-STAGE-BI AS-PLAN>. 
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Figure  IV.G  Bias  Plans 


This  plan  defines  the  bias  netuorks  of  Fig.  1.2. 

The  biasing  plan  interacts  with  the  coupling  plan  for  BJTs  <*COUPLE-NET>, 
which  itself  has  several  SPEC-SCHEMAs.  The  general  plan  is  shown  in  Fig. 
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TYPE 

Figure  IV. 7 General  BJT  Coupling  Plan 


The  interaction  starts  with  the  rule  that  coupling  is  considered  before 
biasing.  <*COUPLE-nEFDRE-BI AS>  (Cf.  Fig.  II. 5.)  The  reasons  for  this  rule 
are  that  decisions  made  during  coupling  often  influence  the  uag  in  which 
biasing  is  done;  and  that  coupling  components  perform  many  biasing  functions. 
These  interactions  depend  upon  the  particular  coupling  network  chosen.  The 
rule  packets  <*COIIPLE-CE-X-HINTS,  COUPLE-CC-X-HINTS>  suggest  particular 
subnets  to  be  used.  One  of  these  <*CE-DI R-VOL-COUPLE-PLAN>  is  shown  in  Fig. 
IV. 8.  (The  others  are  as  yet  unwritten.) 
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Figurp  IV.8  Comnion-Em  i t ter  Direct  Voltage  Coupling 
Choosing  this  plan  amounts  to  settling  on  direct  coupling  with  voltage  as  the 
medium.  Picking  it  reduces  tasks  from  the  bias  network  and  main  coupling  plan 
without  further  examination. 

Two  plans  for  fixing  voltages  is  shown  in  Appendix  3.  <»VS-FIX-V,  VD-FIX- 
V>  The  first  is  used  to  set  voltages  absolutely.  The  second  is  used  for 
sotting  voltages,  such  as  the  base  voltage  of  an  transistor,  which  are  to  be 
allowed  to  change  incrementally. 
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IV. B. 4 Electronics  Analysis  Knouledge 

In  the  usual  case,  there  is  no  special  electronics  analysis  knou I erlge. 
Device  properties  are  expressed  by  numerical  constraints  (Chapter  III),  uhich 
interact  with  each  other  and  SELECT-VALUE  tasks  to  produce  results.  In  the 
ideal  case,  the  deductions  involved  are  always  "one-step  deductions"  (Stallman 
and  Sussman,  1B7G)  of  the  value  of  one  variable  at  a time.  (I  have  taken  much 
of  the  analysis  knoiiledcje  practically  verbatim  from  Stallman  and  Sussman’ s 
data  base. I 

Besides  calculations  of  physical  quantities  and  component  values,  there  is 
also  the  problem  of  computing  values  of  "generic  control  quantities"  (Sect. 
III.A.l).  These  are  quantities  like  "voltage  gain,"  uhich  is  riefined 
generically  as,  "Tfie  value  of  the  voltage  on  the  outport  over  the  value  on  the 
inport,"  but  whose  symbolic  and  numerical  values  depend  on  the  circuit 
involved.  Uhen  a generic  attribute  value  is  constrained,  a task  will  be 
created  to  calculate  it.  <*nENERIC-CAS-DO  in  Appendix  2> 

How  this  is  done  depends  on  the  quantity  to  be  calculatetl.  For  example, 
to  calculate  the  Thevenin  impedance  of  a circuit  from  two  terminals,  you  must 
enter  the  reference  point  (ISOIATE  |trmin  1|  jlrmin  2|1,  fix  the  voltarje  at 
the  two  terminals,  and  calculate  the  current,  (This  technique  Is  probably 
beyond  the  current  competence  of  NASL.  For  a precise  account  of  how  to  do  it, 
see  Doy I e,  1977, I 

Very  little  electronics  analysis  knowledge  has  been  implemented,  (See 
Sect.  IV.O.  below. I fly  implementation  has  focussed  on  qualitative  reasoning 
about  design;  it  complements  the  work  of  Stallman  and  Sussman  (197BI  on 


quantitative  analysis. 
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IV. C Device  Schemata 

Ttip  la<)t  part  of  Appenrlix  3 i a liag  of  tipvi  e nchrmata.  These  inr.  Iiirfe 
primitive  components  anri  a feu  composite  flevices.  Most  of  the  primitive 
componen  t s are  rip  fined  entirely  by  one  or  tuo  constraints  and  some  T anrl  N 
formulas  desc.rlbing  their  behavior  from  various  derived  models.  The 
transistor  schema  ••♦(T  IT-(lErN>,  as  you  might  expect,  has  a more  compi  icaterl 
structure.  Besides  the  physical  constraints  on  its  terminal  voltages  and 
currents,  every  transistor  must  be  biased  into  its  desired  region.  Thus,  a 
composite  device  schema  that  specifies  that  its  transistor  is  active  nil  I 
automatically  acquire  an  expansion  obligation  to  bias  the  transistor. 

There  are  several  device  schemata  for  composite  devices  defined  at  the  end 
o f Append i X 3 : 

GENLBA(,-CE  --  The  most  abstract  common-emitter  circuit 

TYPICAL  CE  --  The  circuit  shown  most  often  in  textbooks,  which  is  derived 
from  the  more  abstract  one 

GENfRAL-fCP  --  The  most  abstract  emitter-coupled  pair 

ECP-DC-AnP  - One  of  many  circuits  that  can  be  derived  from  the  ECP 

VD  --  The  humti  I p voltage  divider 

RC  --  The  filter,  not  the  cola. 

The  relation  between  the  ECP-DC-Af1P  and  its  "soul,"  the  GENERAL-ECP,  is 


shown  in  Fig.  I V,  9 
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Figure  I V . ri  Geripral  and  Spec  i a I i zed  Em  i 1 1 er -Coup  I ed  Pairs 
A similar  relation  exists  hetiieen  GENE.RAL-CE  anri  TYPICAL  CE.  In  defining 
these  relations,  extensive  use  is  made  of  the  [irerlicates  REDUCE  and  FLINCTlflN, 
defined  in  Appenilix  ?.  REDUCE  declares  that  some  set  of  tasks  is  a compit'te 
sulinetuork  of  ttie  rerlucerl  task.  [E  UNCTION  |devl  Irrrdured  task|l  is  a ''.per.  i a I 
case,  used  in  rievire  schemata,  which  declaies  tt>e  existence  Of  an  al’Stract 
task  f nr  acgu  i r I ng  t tie  rle  v i ce  de  v , anrl  s|iec  ifies  ttiat  this  task  is  sufficient 
to  accomplish  the  task  to  he  reducerl. 

The  function  IDRl.  ldev|  |actionll  denotes  an  expansion  task  created  bg  the 
use  of  rule  »*EXPANS 1 riN-ORLS-DOx , defined  in  Appendix  2. 
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IV.D  Programmer ' 9 Guide 


As  I have  pointed  out  in  several  places,  the  information  in  ZflPIH  is 
sketchy.  I hope  this  hasn’ t harmed  the  clarity  of  my  pr  esen  t a t i on;  I have 
provided  an  example  of  every  kind  of  construcl  I discussed.  The  knouledrje 
shown  is  still  in  the  process  of  being  debugged  and  assimilated  into  DESI: 
there  has  not  tteen  time  to  be  complete.  As  it  is,  implementation  and 
debugging  cannot  keep  up  with  generation  of  new  forirulas.  (See  Chapter  V.) 

This  section  is  included  as  a guide  to  anyone  who  wishes  to  add 
information  to  the  flfSI  system  (or  its  successor).  It  consists  of  a list  of 
all  the  kinds  of  information  that  are  missing.  (Filling  in  these  tioles  should 
be  a matter  of  following  the  principles  of  Sect.  III.F  and  imitating  fh»> 
formulas  that  already  exist.) 

> Pephrasing  can  he  extenried.  More  principles  are  neederl  for  cnmparinij 
frer|uency  pictures;  some  knowledge  of  Fourier  transforms  (as  np|)osed  fo  *’ 
freguency  pictures)  is  necessary  in  order  to  generate  precise  side  tasks. 

> The  time-domain  information  is  non-existent  in  Appendix  3.  The  time- 
domain  rephrasing  problem  comes  down  to  trying  to  find  a functional 

r e I a t i rrnsh  i p between  two  ax i oma t i ca I I y described  objects.  This  is  not  easy. 

> Many  more  circuits  are  needed.  Most  of  the  amplifier  types  ment  inner)  in 
<*CHOOSE-AnP?  and  its  satellites  are  undefined;  power  amplifiers  are  a glaring 
omission.  The  superordinate  category  of  "filter"  is  entirely  absent.  There 
should  be  a theory  of  LC  filters  and  when  to  use  one  of  them.  This  should 
work  with  a theory  of  matching  impedances  during  coupling  of  power  stages. 
Time-domain  reptirasing  will  be  useless  unless  it  is  used  to  index  clippers, 
rectifiers,  and  other  "operational"  circuits. 

> Coupling  circuits  are  many  and  varied.  Only  one  specialized  circuit  is 
shown  in  Appendix  3.  (See  Fig.  IV. 8.)  One  difficulty  I didn’t  mention  in 
discussing  coupling  is  choosing  polarities  of  bipolar  transistors.  These  are 
normally  NPN,  but  coupling  them  directly  often  constrains  them  to  he  of 
opposite  polarities. 

> Some  of  the  information  shown  hanging  off  circuit  diagrams  in  Chapter  I, 
especially  interface  constraints,  has  not  been  represented  in  the  circuit 
echemata  of  Apjiendlx  3.  For  example,  the  system  function  of  the  RC  filter 
will  not  be  what  it  claims  to  be  if  something  is  connected  to  it. 
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These  problems  are  the  ones  I’ve  thought  about,  and  sketched  answers  for. 
There  are  many  more  I haven’t  thought  of. 
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V Kesults 

The  major  result  o*  this  research  to  date  is  the  existence  of  NA5L , DfSI. 
and  ZORCH.  The  experience  I have  had  in  defining  the  NASL  notation  anr( 
applying  it  to  electronic  circuit  design  is  enough  by  itself  to  suggost 
certain  conclusions.  These  are  the  substance  of  Chapter  V|. 

Of  course,  the  claims  I make  there  nil  I be  not  be  decisively  proynn  unMI 
the  program  has  been  debugged  and  the  ZORCH  knowledge  base  has  been  complnferl. 
These  activities  are  proceeding,  and  preliminary  results  are  reportetl  in  ''met. 
V.B  below. 

Since  DESl  is  intended  to  be  a working  system,  and  since  people  mag  iii''.h 
to  experiment  with  it  or  with  the  NASL  interpreter,  these  are  desrr  i herl  from  a 
practical  point  of  view  in  Sect.  V.A.  I would  appreciate  comments  from  those 
who  try  it  out. 

V.A  Using  DESI 

V.A.l  Loading  and  Running  the  Program 

To  run  my  programs  on  the  tllT  AI  Lab  time-sharing  system,  type 
: I dvm; 
at  DOT,  then 

f I oad  nas I ) 

at  LISP.  This  will  load  the  interpreter  and  leave  you  in  the  MSP  reatl-eval- 
print  loop.  (The  reader  and  printer  are  not  the  standard  LISP  medianisms,  hut 
that  shouldn’t  matter.)  Now  you  can  load  NASL  assertions  from  any  file  you 
choose  (using  DEFflLA;  see  Appendices  2 and  3).  To  load  the  designer  in,  type 
(load  desi)  instead  of  or  in  addition  to  the  above:  to  load  ttie  electronics 


V Rr  <111 1 t T 


IM 


knoulerige.  type  (load  zorch)  . (Or  load  the  binary  file  TS  DE5I  , to  navn  lot 
of  time.) 

To  run  NASL,  type 

(start  I ac  t I on  I ) 

at  LISP,  uhere  action  Is  a formula  or  list  structure  of  the  form  (/:TASk  ...) 
or  (lactlon  f unc t i on | . . . ) . (In  the  latter  case,  if  the  action  has  outputs, 
type  (start  (action)  |outputs|).)  NASL  ui I I begin  execution,  adding  tt\n  rmu 
action  to  its  task  network.  Uhen  the  network  is  empty,  it  will  return  thp 
output  variables  of  action  if  any.  It  will  also  remain  in  the  data  pool  of 
the  action  performed,  typically  a DESIGN,  so  that  you  can  run  new  tasks  in  the 
same  environment.  . 

V.A.2  DESI  Talks  to  You 

Uhen  NASL  runs  into  trouble,  or  needs  the  answer  to  a symho  I -man  i pu  I a t i on 
problem,  it  stops  and  asts  you  questions  to  try  to  help  Itself  out.  "Trouble" 
is  defined  as  the  failure  of  the  choice  or  rephrasing  protocol  to  acfnevn  its 
aims.  In  either  case,  the  system  stops  and  tells  you  its  trouble,  thm  asks 
various  questions.  For  example,  if  it  cannot  make  up  its  mind  after  applying 
all  the  known  choice  rules,  it  will  ask  if  it  should  choose  at  random.  Yes/no 
questions  are  answered  by  typing  "yes,"  "y,"  "no,"  or  "n."  Other  quesfions 
will  be  requests  for  formulas.  (If  you  type  an  S-expression  where  a foimula 
is  wanted,  NASL  will  convert  it.) 

Three  stanriard  questions  and  the  reactions  to  their  answers  are: 

> "Do  you  want  to  see  the  reasoning  involved?"  Answering  affirmatively 
causes  NASL  to  re-run  the  most  recent  relevant  deduction,  with  the  switcbec, 
STP-TRACE-DEPTH*  and  RECORO-SEE-OEPTH*  set  to  values  that  let  you  see  the 
steps.  (See  below. ) 
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> "Break?"  If  you  answer  "yes,"  the  system  will  give  you  a I I5P  in  •■.ik 
loop.  This  is  usually  used  for  adding  new  information  to  the  system  iiith 
further  DEFtILAs.  (DEFtlLA  may  be  used  to  redefine  old  formulas,  too.  I Uhen 
you  return  from  the  break,  the  next  question  in  NASL’s  list  will  he  askefl. 

> "Try  again?"  Don’t  say  "yes"  unless  you've  taken  advantage  of  ttu-  break 
loop  and  added  a new  choice  principle,  a missing  axiom  that  was  neefieil  hy  the 
last  deduction,  or  some  other  rule. 


V.A.3  You  Talk  to  DESI 


There  are  several  useful  programs  for  getting  debugging  information  or 
explanations  of  behavior  from  DESI. 

(TASK-NET-DUnP)  causes  the  entire  active  or  pending  task  network  unrler 
your  original  request  to  be  printed  Out  in  a somewhat  readable  farbion.  with 
indeutat ion,  successor  pointers,  etc.  (This  function  takes  an  optional  t.ask- 
name  argument:  if  it  is  omitted,  your  original  request  is  used  as  a riefault.) 

(UHY  I task  I ) causes  the  task  network  above  the  named  task  to  be  rlomurri. 
Notice  that  asking  this  question  about  a frozen  task  will  show  you  par  t of  the 
teleological  structure  of  the  device  it  appears  in. 

(SUPPORT  I fact  1 1 prints  the  supporters  of  the  fact. 

(PURPOSE  Idevice!)  pr-ints  out  the  supertasks  associated  with 
ACQUIPE-ing  the  device  (depending  on  what  kind  of  records  of  the 
the  device  have  been  kept). 

I am  being  a little  vague  about  the  precise  formats  of  these  functions, 
both  because  the  system  encourages  you  to  be  vague  (it  will  try  to  figure  out 
whether  you  are  referring  to  formulas  by  name  or  pattern);  and  because  the 
features  these  functions  support  are  changing  rapidly. 

Some  useful  statistics-gathering  functions  are  defined  in  the  file  SNAP. 
The  statistics  gathered  include  running  times  overall,  time  spent  doing 
matching  and  indexing  (important  low-level  functions  of  a rule-based  system), 
and  success  of  the  indexer  in  keeping  garbage  from  reaching  the  matcher. 

Typing  "(SNAP)"  at  LISP  causes  these  statistics  to  be  printed  out.  "(SNAP 
RESET)"  resets  them;  this  must  be  done  once  to  turn  them  on.  (Collecting 
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these  statistics  sinus  things  doun  someuhat.) 

There  are  several  suitchps  uhose  settings  affect  the  verhiagn  i rlur  r-d  hy 
the  NASL  system.  These  suitches  are  printed  by  the  function  SHOU-SUl U III 
defined  in  SNAP.  The  suitch  NASL-TRACE-DETAIL*.  an  integer  frnm  R to  ahniil  S. 
defines  hou  much  the  interpreter  uill  tell  you  about  its  every  move.  The 
suitch  STP-TRAEE-DEPTH*  controls  printing  of  major  sub-goal  Informal  inn  hy 
STP;  if  zero,  nothing  is  printed.  Similarly,  RECORD-SEE -DEP IH*  controls 
printing  of  data-base  alterations.  Both  of  these  suitches  are  normally  rein; 
the  system  sometimes  turns  them  on  to  display  inferences  or  model  effor  ts. 

(As  in  Sect.  V.0,  belou.) 

V.B  Experimental  Results 

The  DESI  system  is  still  being  debugged.  Consequently,  it  has  never 
designed  a circuit  all  the  uay  through.  It  has  done  simple  choice  analysis, 
trivial  equation  solution,  and' some  rephrasing  of  simple  conjunctive  rlesltin 
prob I ems. 

Most  of  the  time,  the  system  runs  uell.  Foruard  deduction  and  task 
reduction  occur  in  a reasonable  amount  of  time;  uatching  the  trace  on  ttie 
screen  is  a pleasant  experience.  The  NASL  language  is  easy  to  program  m;  it 
encOiJrages  an  incremental  style  of  programming  in  uhich  partial  plans 
interact.  If  an  unforeseen  interaction  occurs,  the  presence  of  all  ta- t< 
information  in  the  rlata  base  usually  makes  the  trouble  easy  to  find;  fixing  it 
is  usually  a matter  of  aitding  a neu  rule.  Uhen  it  isn’t,  the  problem  iirnilly 
turns  out  to  he  a syntactic  error  in  a rule;  I strongly  recommend  to  future 
designers  of  predicate-calculus  systems  with  large  rule  bases  that  they 
include  checks  of  syntax  (such  as  proper  number  and  type  of  arguments  tn 
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pr  *»d  i ca  t p«i  t at  thp  t I ntp  a rule  19  read.  In  such  a system,  a urotuj  ruin  is 
often  overlooked  entirely. 

Calls  to  the  theorem  prover  tend  to  slow  things  down.  This  not  her.iure  of 
any  coir^jinator  iai  explosion.  Put  probably  because  of  the  theorem  provei  's 
carefulness  in  checking  subsumption  and  other  special  cases  whicti  are  normally 
irrelevant.  The  theorem  prover  is  probably  too  complex  for  its  own  tjoml;  the 
next  such  prorjram  I write  will  be  much  more  like  Conniver.  (McDermott  and 
Sussman,  1973) 

Furthermore,  the  evaluation  mechanism  (Appendix  4),  which  is  normally 
quite  efficient,  wastes  much  time  in  other  c ircumstances.  The  evaluator  is 
called  whenever  the  right-hand  side  of  an  implication  is  detacher!  rlur  inij 
deduction.  It  tries  to  apply  reduction  rules  to  every  new  subexpr ess i nn  nf 
the  detached  formula.  This  Isn’t  nearly  as  expensive  as  it  soumls,  peraiire 
one  quick  index  call  is  enough  to  check  the  (very  common)  case  where  fhr're  are 
no  applicable  rules.  Unfortunately,  In  detaching  the  right-hand  sirle  nl  a 
large  implication  like  <*rOE’SI-2>  in  Appendix  2,  there  is  an  emharassinri 
pause.  I am  putting  up  with  this  for  the  time  being,  but  it  is  clear  that 
this  is  a job  for  some  further  pragmatic-predicate  mechanism. 

As  it  stands,  the  system  with  ZORCH  loaded  occupies  a huge  amount  nl  r nr  e. 
As  incomplete  as  it  is,  it  takes  up  about  220K  of  3G-bit  word  storage.  Ahnui 
50k  of  this  IS  the  I I SP  system  and  my  low-level  utilities,  and  1 3Pk  is  list 
space,  70X  (atmut  SPkl  of  which  19  occupied.  Of  this,  about  30k  consists  of 
circuit  diagrams  for  the  five  device  types  defined  in  ZORCH'  1 am  sure  Hus 
can  he  brought  down  by  judicious  rearrangement  of  consequent  vs.  antoi  ndi'nt 
deduction!  the  firoblem  ap|iears  to  be  overenthus  i as  t i c forward  reasnninu  nh  1 I n 


setting  up  rjevire  schemata.  However,  a lot  of  storage  is  reguirerl  to  sf<  I u|i 
and  index  packets,  whether  they  are  used  later  or  not.  To  duck  this  pinlH’lm, 
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in  the  sample  runs  given  below,  large  conjunctions  of  the  form  ...1 

were  actual  Ig  implemented  as  ordinary  formulas  like  (AND  ...1.  In  thn  lone) 
nm,  we  are  going  to  have  to  confront  the  question  of  organizing  sncnnrl.v  i/ 
storage  for  use  by  Al  programs. 

There  are  three  experimental  results  to  demonstrate.  First  (Sect.  V.E3.1), 

I present  DESI’s  attempt  to  design  a simple  amplifier.  Then  I show  its 
pitiful  approach  to  the  f I I ter -des i gn  problem  I described  in  Chapter  i.  In 
both  these  cases,  the  program  crashed  due  to  bugs  before  going  as  far  as  it 
is,  in  theory,  capable.  Finally,  in  Sect.  V.B.3,  I discuss  some  research  with 
Jon  Doyle  Into  the  relation  between  NASL  and  NOAH.  (Sacerdoti,  197S) 


V.B.I  A Simple  Amplifier 


Here  is  a sample  output  from  a run  of  DESl  on  the  first  problem  in  fdiapter 

I,  with  NASL-TRACE-DETAIL*  set  to  3.  fly  comments  start  with  The  output 

has  been  edited  .to  relieve  the  tedium.  The  dots  "..."  indicate  nmissinns.  In 

this  and  the  next  section,  apparently  random  "I's"  In  the  output  are  causerl  iiy 

garbage  collection,  one  exclamation  point  per  collection.  Long  strings  of 

these  marks  are  indicative  of  long  pauses  between  outputs. 

sThe  system  was  started  with  by  typing 
I (start  '(design  ...)  ' [ <' I w i nner I >1  : 

(CREATING  task: 

(iTASK  (mDESm)  <>  (LAriBDA  NIL 

(DESIGN  (LAMBDA  (X) 

(AND  (DEV-TYPE  ?X  AMPLIFIER  I 
(-  (V-GAIN  ?X»  5) 

(-  (INPUT-Z  ?XI  30000))))) 

<’  (UINNEH) >I ) 

(ENABLED  ((*nfS*)l) 

(EXECUTING  ((*DLS*)1  ...I 
(TAS)i.  ((*OES*l)  Bfc  I NG  REDUCED) 

(TASK  ((*DES*)1  TO  BE  REf’HRASED) 

(CREATING  TASK  (:TASK  (REPKRASER  (*0ES*)l 


j. 


A 


J 


\ 

V Rpqij  I t 9 1 Sf> 


(LAMODA  NIL 

(rREPHRASE  (»OES*>  (DESIGN  (LAflBOA  (X) 

(AND  ...ni 

<• (U1NNER)>)I 

<>)  I 


(ENABLED  (REPHRA5ER  (*DES*m 
(EXECUKNG  '(REPHRASER  (*DES*)1 

(:REPHRA5E  (*DE5*)  (DESIGN  (LAMBDA  (X) 

(AND  (DEV-TYPE  ?X  AMPLIFIER) 

(-  (V-GAIN  ...)  51 
(-  UNPUT-Z  ...)  30000)1)1 

<•  (UINNER)>) 

(<>) ) 

(TASK  (REPHRASER  (*DES*)1  BEING  REDUCED) 

(TASK  (REPHRASER  (♦DES*)1  REDUCED  TD 
(:DO-SUBNET  (DES I -REPHRASE -PLAN 

((LAMBDA  (X)  (AND  ...))1  (*OES*)  <’(U(NNER)>) 
<>)) 

<>)) 

;Here  are  the  tasks  from  the  DESIGN  rephrase  plan  <*-»-DESI-2> 
(CREATING  TASK  (:TASK  (EXPLODER  PLANff380) 

< > 

(LAMBDA  NIL 

(D-EXPLODE  ((LAMBDA  (X) 

(AND  ...))))) 

<>1  ) 

(CREATING  TASK  (:TASK  (ACCOUNT -FOR -ALL  PLANO380) 

< > 

(LAMBDA  NIL 

(ACCOUNT-FOfl-ALL-SHARDS  ((LAMBDA  (X) 

(AND  ...mn 

<>) ) 

(CREATING  TASK  (tTASK  (CORE -FINDER  PLANW380) 

<> 

(LAMBDA  NIL 

(tFIND  (LAMBDA  (+OT) 

(CORE-DEV-TYPE  (...1  ?^OT)))) 

<’ (CDRE-DT  PLANtf380)>n  ! 

(CREATING  TASK  (:TASK  (MAIN-TASK-INFERER  PLAN«380) 

<• (CORE-OT  PLANtf380)> 

(LAMBDA  (+DT) 

(:  INFER  ’(AND  (STASK  (MAKER  ...)  (*v.ES») 

<> 

(LAMBDA  NIL 
. . . ) 

<...>) 

(:MAIN  (MAKER  ...)  (*OES*) ) ) 

< (CORE -FINDER  PLANO380) >) ) 

<>) ) 

(CREATING  TASK  (:TASK  (SI DE -TASKS-F INOER  PLANO380) 


(LAMBDA  NIL 
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(: INFER  • (FORALL  (+ST)  (->  G (SIDE-TASK  ...) 

(EXISTS  . . . n ) 


<>]  » 

(CREATING  TASK  (:TA5K  (FEATURES-F I NDER  PLAN<(380) 

< > 

(LAnBDA  NIL 

(: INFER  ’(FORALL  (+FT)  (->  G (D-FEATURE  ...) 

(EXISTS  ...))) 

<>) » 

<>1 ) 

(CREATING  TASK  (:TASK  (GATHERER  PLAN/K380) 

< > 

(LAMBDA  NIL 

(: INFER  ’(:REDUCED  (»OES«) ) 

< (CORE-FINDER  PLAN»380) 

(SIDE-TASKS-FINOER  PLAN»380) 
(FEATURES-FINOER  PLAN«380)>») 

<>1  ) ' 

(BLOCKED  IMA  IN-TASK- 1 NFERER  PLANW3801) 

(BLOCKED  (CORE -FINDER  PLANW3801) 

(ENABLED  (ACCOUNT -FDR-ALL  PLAN/K380J ) 

(BLOCKED  (EXPLODER  PLANtt380)  I 
(BLOCKED  (GATHERER  PLANW3801  ) 

(BI.OCKED  (FEATURES-FINOER  PLAN«380] ) 

(BLOCKED  (SIDE-TASKS-FINDER  PLANff380I) 

;The  only  task  which  ig  enabled  is  the  policy-setup  for  shard 
; accoun  t i ng-- 

(EXECUTING  (ACCOUNT -FOR -ALL  PLANtf380) 

(ACCOUNT-FOR-ALL-SHARDS  ((LAMBDA  (XI 

(AND  (DEV-TYPE  ?X  AMPLIFIER) 

(-  (V-GAIN  ...I  5) 

(-  (INPUT-Z  ...I  30000)1) n 

(oil  ' 

(TASK  (ACCOUNT -FOR-ALL  PLAN»380) 

BEING  REOUCED) 

(TASK  I ACCOUNT -FOR -ALL  PL AN«380) 

REDUCED  TO  (-.PRIM  *SETUP1) 


;But  the  first  real  task  is  the  exploder 

(ENABLEO  (EXPLODER  PLAN//380) ) 

(EXECUTING  (EXPLODER  PI  ANff380) 

(D-EXPLOOE  ((LAMROA  (X) 

(AND  (DEV-TYPE  ’X  AMPLIFIER) 

(.  (V-GAIN  ...I  5) 

(.  (INPlJT-Z  ...)  30000)1)1) 

(ol ) 

(TASK  (EXPLODER  PLANW380)  BEING  REDUCED) 

(TASK  (EXPLODER  PLAN»380)  REOUCED  TO 

(i  INFER  • (0 -SHARD  ((LAMBDA  (X)  (AND  ...))) 


J 


d 
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<>)) 


((LAMBDA  (X)  (AND  ...)))) 


;The  system  prints  out  a lengthy  list  of  deductions  from  this  inferrefi 
j "d-sharri": 

(INFERENCES  MADE  BY  (EXPLODER  PLANff380I 
--) 

(RECORDING  (D-SHARD  ((LAMBDA  (X) 

(AND  (DEV-TYPE  ?X  AMPLIFIER) 

(-  (V-GAIN  ...)  5) 

(.  (INPUT-Z  ...)  30000)1)1 

((LAMBDA  (X) 

(AND  (DEV-TYPE  ?X  AMPLIFIER) 

(-  (V-GAIN  ,..)  5) 

(-  (INPUT-Z  ...)  30000))))) 


ilt  turns  the  elements  of  the  conjunction  into 
(RECORDING  (:GEN  (NOT  (ELT  ?+C^A  < (DEV-TYPE  ?X 

(-  (V-GAIN  . 
(-  (INPUT-Z 
(D-SHARO  ((LAMBDA  (X) 

(AND  (DEV-TYPE  ... 
(-  ...  5) 

(-  ...  30000)))] 
((LAMBDA  (X)  _?+C^4))M 

0)  ) 


shards 

AMPLIFIER) 

..)  5) 

...)  30000] >)) 
AMPLIFIER) 


j The  first  of  three  major  shards: 

« • , 1 

(RECORDING  lO-SHARO  ((LAMBDA  (X) 

(AND  (DEV-TYPE  ?X  AMPLIFIER) 
(-  (V-GAIN  ...)  5) 

(-  (INPUT-Z  ...)  30000)))) 
((LAMBDA  (X)  (-  (INPUT-Z  ?X)  30000)))) 

0) 


I The  tells  DESI  one  side  might  be  a control  quantity: 

(RECORDING  IPOS-CQ-SHARO  ((LAMBDA  (X) 

(AND  (DEV-TYPE  ?X  AMPLIFIER) 
(-  (V-GAIN  ...)  5) 

(-  (INPUT-Z  ...)  30000)))) 
(X)  (INPUT-Z  ?XI  (300001) 

0) 

(RECORDING  (:GEN  (NOT  (AND  (NOT  (CONTAINS  (30000)  (??  X) ) ) 

(->  • (DEN  ...)  ?F^9) 
(CONTROL-ATTRIBUTE  ?F"9) 

(->  • (DEN  ?+F"9)  ?F''9))) 
(SIDE-TASX  ((LAMBDA  (X) 

(AND  (DEV-TYPE  ...  AMPLIFIER) 
(-  ...  5) 
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30000)))] 

((LAMBDA  (X)  (CONSTRAIN  <.. .>  (LAMBDA  ...I))))) 

0) 

(RECORDING  (P0S-CQ-5HARD  ((LAMBDA  (X) 

(AND  (DEV-TYPE  ?X  AMPLIFIER) 

(-  (V-GAIN  ...)  5) 

(-  (INPUT-Z  . . . ) 30000) ) ) 1 
(XI  (300001  (INPUT-Z  ?X)J 

0) 

(RECORDING  (:GFN  (NOT  (AND  (NOT  (CONTAINS  (INPUT-Z  ...I 

(??  XI)) 

(->  • (DEN  . . . ) ?F'‘9) 

(CONTROL-ATTRIBUTE  ?F^9) 

(->  ' (DEN  ?+F^9)  ?F^9))) 

(SIDE-TASK  MIAMBOA  (X) 

(AND  (DEV- TYPE  ...  AMPLIFIER) 

(-  ...  5) 

(-  ...  30000)))] 

(UAMBOA  (X)  (CONSTRAIN  <...>  (LAMBDA  ...)))1)1 


0)  ' 


;Having  noticed  that  INPOT-Z  Is  a control  attribute, 
t INPUT-Z-SHARD  to  classity  the  desired  impedance: 


i t uses  the  ru I e 


(RECORDING  (:GEN 


(NOT 

(AND 


0) 

(RECORDING 


(AND 


(.  30000  ?Z''7)) 

(:GEN  (NOT  (>  ?Z'‘7  300000.0)) 

(D-FEATURE  ((LAMBDA  ...)] 

(RANGER  INPUT-Z  VERY-HIGH] ) 
(:GEN  (NOT  (AND  (>  ?Z"7  1500.0) 

(<  ?Z"7  500000.0))) 
(D-FEATURE  I (LAMBDA  ...)) 

(RANGER  INPUT-Z  HIGH) ) ) 
(:GEN  (NOT  (AND  (>  ?Z"7  500) 

(<  ?Z''7  2000.0))) 

(D-FEATURE  ((LAMBDA  ...)1 

(RANGER  INPUT-Z  MODERATED) 
(:GEN  (NOT  (<  ?Z"7  1000)) 

(D-FEATURE  ((LAMBDA  ...)) 

(RANGER  INPUT-Z  LOU))))) 


(:GEN  (NOT  (>  30000  300000.0)) 

(D-FEATI.IRE  ((LAMBDA  (X)  (AND  ...))) 

(RANGER  INPUT-Z  VERY-HIGH])) 

(NOT  (AND  (>  30000  1500.0)  (<  30000  500000.0))) 


(;GEN 

(D-FEATURE  ((LAMBDA  (X)  (AND  . 
(RANGER  INPUT-Z  HIGH))) 
(:GEN  (NOT  (AND  (>  30000  500)  (< 
(□-FEATURE  ((LAMBDA  (X)  (AND  . 
(RANGER  INPUT-Z  MODERATED) 
(:GEN  (NOT  (<  30000  1000)) 

(D-FEATURE  ((LAMBDA  (X)  (AND  . 
(RANGER  INPUT-Z  LOUD)) 


..))) 

30000 

..))) 


3)1 


2000.0) ) ) 


0) 
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jThe  winning  feature  is  "high  input  im|)pdance": 

(RECORDING  ID-FEATURE  ( (LAnDDA  (X) 

(AND  (DEV-TYPE  ?X  AMPLIFIER) 
(-  (V-GAIN  ...)  5) 

(-  (INPIJT-Z  ...)  30000)))) 
(RANGER  INPUT-Z  HIGH)) 

0) 


;A  similar  deduction  is  done  for  the  case  of  voltage  gain: 

(RECORDING  (D-SHARD  I (LAMBDA  (X) 

(AND  (DEV-TYPE  ?X  AMPLIFIER) 

(.  (V-GAIN  ...)  5) 

(-  (INPUT-Z  ...)  30000)))) 

((LAMBDA  (X)  (-  (V-GAIN  ?X)  5)))) 

0) 

(RECORDING  (POS-CQ-SHARD  I (LAMBDA  (X) 

(AND  (DEV- TYPE  ?X  AMPLIFIER) 

(-  (V-GAIN  ...)  5) 

(-  (INPUT-Z  ...)  30000)))) 

IX)  (V-GAIN  7X1  (51) 

0) 

(RECORDING  (POS-CQ-SHARD  ((LAMBDA  (X) 

(AND  (DEV-TYPE  ?X  AMPLIFIER) 

(-  (V-GAIN  ...)  5) 

(-  (INPUT-Z  ...)  30000)))) 

(X)  (5)  (V-GAIN  ?Xn 

0) 

(SIDE-TASK  ((LAMBDA  (X) 

(AND  (DEV-TYPE  ?X  AMPLIFIER) 

(.  (V-GAIN  ...)  5) 

(-  (INPUT-Z  ...)  30000)))) 

((LAMBDA  (X) 

(CONSTRAIN  <’...>  (LAMBDA  (Gl)  (-  ...  5)))))) 


(RECORDING  (AND  (:GEN  (NOT  (>  5 1000))  (D-FEATURE  ((LAMBDA  (X) 

(AND  ...))) 

(RANGER  V-GAIN  VERY-HIGH))) 
(:GEN  (NOT  (AND  (>  S 50)  (<  5 5000))) 

(0-FEATIIR(  KLAMBDA  (X)  (AND...))) 

(RANG[R  V-GAIN  HIGH))) 

(:GEN  (NOT  (AND  (>  51)  (<  5 100))) 

(D-FEATURE  ((LAMBDA  (X)  (AND  ...))) 

(RANITLR  V-GAIN  MODERATED) 

(:GEN  (NOT  (-<  5 D)  (D-FEATURE  I (LAMBDA  (X)  (AND  ...))) 


V Regu I t a 


0) 


(RANGER  V-GAIN  LOU)  Ml 


(RECOROiNG  (DMEATLIRE  MLARBOA  (K) 

(AND  (DEV-TYPE 
(.  (V-GAlN  . 
(.  (INPUT-Z 

[RANGER  V-GAIN  nOOERATEl) 

0) 


?X  ARPLIFIER) 
..)  5) 

...I  30000)))) 


: The  last  rt-shard  gives  us  the  core  device  type: 

(RECORDING  (D-SHARO  I (LATIBOA  (K) 

(AND  (OEV-TYPE  ?X  ATIPLIFIER) 

(-  (V-GAIN  ...I  51 
(-  (lNPUT-7  ...)  30000)))) 
((LAdROA  (X)  (DEV-TYPE  ?X  AMPLIFIER)))) 

0)  ' 

(RECORDING  (CORE-DEV-TYPE  [(LAMBDA  (X) 

(AND  (DEV-TYPE  ?X  AMPUFIER) 
[-  (V-GAIN  ...)  5) 

[-  (INPUT-Z  ...)  30000)))) 

(AMPLIFIER) ) 

0) 

(♦INFERENCES  DONE*) 


;This  concludes  the  inferences  of  the  exploder 

;Now  the  other  tasks  of  the  rephrasing  plan  assemble  the  features. 
;device  type,  and  constraints  into  a new  task  notuorki 

(ENABLED  (FEATURES-FINDER  PI ANA380)  ) 

(ENABLED  (CORE-FINDER  PLANff3801 ) 

(EXECUTING  (CORE-FINDER  PLAN»380) 

(iFlNO  (LAMBDA  (^-DT) 

(CORE-DEV-TYPE  ((LAMBDA  (X) 

(AND  ..Ml 

?+OT) ) 1 

[<• (CORE-DT  PLAN«380)>) ) 

(TASK  (CORE-FINDER  PLAN//3S01  PRIMITIVE)  ' 

(OLD  TASK  (MAIN-TASK-INFERER  PLAN«380) 

HAS  ACTION  (:1NFER  '(AND  (STASK  (MAKER  (*OES*M 

(*DES*) 

<> 

(LAMBDA  NIL  (MAKE  (DEN  ,..))) 

<• (DINNER  ...)>) 

(:MA(N  (MAKER  (*OES*) I 
(*0ES*)M 

< (CORE -FINDER  PLANff380)>)) 

(ENABLED  (MAIN-TASK-INFERFR  PLANW3801 ) 

(FINISHED  (CORE -FINDER  PLAN(/380M 


IGl 


cor  o 


{Retrieval  of  the  core  device  type  enables  (he  system  to  infer 
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; the  main  ta''k: 

(EXECUTING  inAIN-TASK-lNf EH(  R PLANtf380) 

t:INFER  • (ANO  (STASK  (MAtCER  (*{1TS*))  (*OES*! 

< > 

(LAMBDA  NIL  (MAKE  (DEN  ...))) 

<• (UINNER  ...l>) 

(:MA!N  (MAKER  (*DES*))  (*OES*m 
< (CORF -FINDER  PLANtfl8R)>] 

(<>] ) 

(TASK  [MAIN-TASK-INFF.RER  PLAN«380I 
PRIMITIVE) 

(INFERENCES  MADE  BV  (MAIN-TASK-INFERFR  PLANtf3801 
--) 

(RECORDING  (:TASK  (MAKER  (♦DES*))  <>  (LAMBDA  NIL  (MAKE  AMPLIFIER)) 

<• (UINNER  )*nES*))>l 

0) 

(CREATING  TASK  I : TASK  (MAKER  (*DES*))  <> 

(LAMBDA  NIL  (MAKE  AMPLIFIER)) 

<’ (UINNER  (.*OES*))>)) 

(RECORDING  (:SUBTASK  (MAKER  (*DES*))  (*OES*)) 

0) 

(RECanOING  [:MAIN  (MAKER  l*nE5*))  (»DES»)) 

0) 

(♦INFERENCES  DONE*)  ' 

jEnd  of  inferences  tjy  main  tas)^  inferer 

(ENABLED  (SIDE-TASKS  FINDER  PLANtf380)) 

(FINISHED  IMAIN-TASK-IN) ERER  PLAN«3801) 

(BLOCKED  [MAKER  (*OES*)l) 

;Nou  the  features  of  the  desired  device  cause  policies  to  he  created: 
(EXECUTING  (FEATURES  f I NOT  R PI  AN</380I 

(:  INFER  • (FORALl  (*FT)  (->G  (D  FEATURE  (...)  7+FT) 

(EXISTS  (T)  (AND  (STASK  ...) 

( : SCOPE  . . . ) 

( I SUCCESSOR  ...))))) 

<>] 

(<>)  ) 

(TASK  (FEATURES-FINDFR  PLANff380) 

PRIMITIVE) 

(INFERENCES  MADE  BY  (FEATURES-FINDER  PLANO380) 

--) 

(RECORDING  (:GEN  (NOT  (D-FEATURE  ((LAMBDA  (X)  (AND  ...))) 

?+F  T) ) 

(ANO  (STASK  TIA00/11GS  (*OES*) 

< > 

(LAMBDA  NIL  (O-NOTE  (DEN  ?+FT))) 

< > ) 

(iSCOPE  TIA00/11FS  (MAKER  (eOES*) ) ) 

(:SUCCESS(JR  T'A00/11G5  (MAKER  (*0ES*))))) 

0) 


d 
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(RECORDING  (:TASK  T'4H0/1G31  <>  (LAnSOA  NIL 

(D-NOTE  (RANGER  INPUT-Z  HIGH))) 

<>) 

0) 

(CREATING  TASK  1:TASK:  T'A00/1G91  <>  (LAMBDA  NIL 

(D-NOTE  (RANGER  INPUT-Z  HIGH))) 

<>)  ) 

(RECORDING  (:SUBTASK  T'A00/1G91  (»0ES*)1 
0) 


jNoting  fhp  SCOPE  of  tfie  (33><.  (riggers  several  rules  for 
:suggesting  uays  to  mal^e  an  amplifier: 

(RECORDING  (:SC0PE  T'A00/1631  (MAKER  (*OES*))) 

0) 

(RECORDING  (:ANTEC  (NOT  (:P0LICY  T'A00/1B91 

(O-NOTE  (RANGER  V-GAIN  MODERATE)))) 

(: TO-DO  (MAKER  (*0ES*))  (MAKE  AMPLIFIER)  <?DEV^29> 
(MAKE  CEDI 

1 

' (RECORDING  (:ANTEC  (NOT  (rPOLICY  T'A00/ieSl 

(O-NOTE  (RANGER  V-GAIN  HIGH) )) ) 

(:  TO-DO  (MAKER  (*0ES*D  (MAKE  AMPLIFIER)  <?DEV^29> 
(MAKE  N-STAGE)I1 

0) 

' (RECORDING  (:ANTEC  (NOT  (rPOLICY  T'A00/1G91 

(D-NOTE  (RANGER  V-GAIN  VERY-HIGH) )) ) 
(:  TO-DO  (MAKER  (*DES*D  (MAKE  AMPLIFIER)  <?DEV^29> 
(MAKE  (TP-AMPD) 

' 0) 

(RECORDING  (:ANTEC  (NOT  (-.POLICY  T'A00/1B91 

(O-NOTE  (RANGER  FREQ-OP  VERY-LOU) I ) ) 
(:TO-DO  (MAKER  (*DES*))  (MAKE  AMPLIFIER)  <?DEV''29> 
(MAKE  OIFF-AMPD) 

0)  ' 

, (RECORDING  (:ANTEC  (NOT  (:POLICY  T'400/1G91 

(D-NOTE  (RANGER  INPUT-Z  HIGH)))) 
(:T0-00  (MAKER  (*DES*D  (MAKE  AMPLIFIER)  <?DEV''29> 
(MAKE  CCD) 

0) 

* (RECORDING  (lANTEC  (NOT  (:POLICY  T'A00/1G91 

(D-NOTE  (RANGER  P-GAIN  HIGH)))) 

(AND  (: TO-DO  (MAKER  (*OES*D  (MAKE  AMPLIFIER) 
<’DEV''23> 

(MAKE  COMP-SYMD 

(:TO-DO  (MAKER  (*OES*D  (MAKE  AMPl  (FIERI 
<?OEV^23> 

(MAKE  PUSH-PULL) FD 

0) 

(RECORDING  (jANTEC  (NOT  (:POLICY  ?PTASK"29  (MAKER  (*DES*) ) 

(O-NOTE  LINEAR))) 

(!  TO-DO  (MAKER  (*OES*D  (MAKE  AMPLIFIER)  <?DEV^29> 


(MAKE  CE))1 


0) 

(RECORDING  (iSUCCESGOR  T'AR0/1B91  (flAKER  (*OES*))l 
0) 

(RECOROING  I:  task:  T'A00/21SA  <>  (LAIIBOA  NIL 

(D-NOTE  (RANGER  V-GAIN  nOOERATEM) 


<>) 


0) 

(CREATING  TASK  (:TASK:  T '400/2154  <> 

(LAHODA  NIL  (O-NOTE  (RANGER  V-GAIN  tlOOERATEm 
<>1 ) 

(RECORDING  (: SUBTASK  T'400/21S4  (*DES*)1 
0) 

(RECORDING  l;SCOPE  T'400/2154  IHAKER  (»OES*)  H 
0) 


;Similarly  for  this  feature: 

(RECORDING  I:ANTEC  (NOT  (:POLICY  T'400/2154 

(D-NOTE  (RANGER  V-GAIN  nOOERATEim 
(:  TO-DO  (MAKER  (*OES*I ) (MAKE  AMPLIFIER)  <?OEV''29> 
(MAKE  CE))I 

0) 

;The  same  rules  will  be  found  again  (a  slight  non-optimality 
; in  the  phrasing  of  the  these  rules) 


(RECORDING  liSUCCESSOR  T'400/2154  (MAKER  l*OES*)M 
0) 

(•INFERENCES  DONE*)  ' 

;End  of  inferences  by  features  finder. 


(FINISHED  IFEATURES-FINDER  PLANO380) ) 
(BLOCKED  IT '400/1G3D  ) 

(BLOCKED  IT '400/21541) 


;The  side-tasks  finder  similarly  turns  side-task  shards  into  CONSTRAIN 
: tasks: 

(EXECUTING  IS  10E-TA6KS -FINDER  PLAN//380) 

I:  INFER  ' (FORALL  (♦ST)  (->  G (SIDE-TASK  I..,)  ?+ST) 

(EXISTS  (T)  (AND  ISTASK  ...) 

(tSUCCESSOR  ...))))) 


<>) 

(<>)) 

(TASK  ISIDE-TASKS-FINDER  PLAN«380) 

PRIMITIVE) 

(INFERENCES  MADE  BY  ISIDE-TASKS-FINDER  PLANA380) 
--) 


(RECORDING  I: GEN  (NOT  (SIDE -TASK  I (LAMBDA  (X) 

(AND  ...m 


?+ST)) 

(AND  (STASK  T'401/G707  (*DES*) 


V 


0) 


<*(UINNER  (*DES*))> 
(DEN  7+5T) 

< > ) 

(:  SUCCESSOR  (MAICER  UDES*)) 
TU4R1/G707))) 


(RECORDING  (:TASl^  T'AOl/SAOG  <’ (WINNER  (*DES»))> 
(LAMODA  IX) 

(CONSTOAIN  <• (V-GAIN  ?X)> 

(LAnnoA  (Gi)  (-  ?Gi  sni) 

<>) 

0) 

(CREATING  TASK  {:TA5K  T'A01/3A06  <’ (WINNER  (*OES*))> 
(LAhRDA  (X) 

(CONSTRAIN  <• (V-GAIN  7X(> 
(LAODDA  (Gl)  (-  ?G1  Sm» 

<>)  ) 

(RECORDING  (: SUBTASK  T'A0J/3A0B  (*DES*)) 

0) 

(RECORDING  (: SUCCESSOR  (MAKER  (*DES») ) 

T'A01/340G) 

0) 

(♦INFERENCES  DONE*) 

;End  of  inferences  by  side-tasf^s  finder. 


(ENABLED  (GATHERER  PLAN«380]) 

(FINISHED  (SIDE-TASKS-FINOER  PLAN</380))  ' 
(BLOCKED  IT'401/3A0G)) 


;The  "gatherer"  just  matVs  the  design  task  reduced: 
(EXECUTING  (GATHERER  PLANW3801 

(:INFER  ’(tOEDUCEO  (*DFS*I ) < (CORE -FINDER  PLAN«380) 

(SIOE-TASKS-FINOER  PLAN/K380) 
(FEATURES-FINDER  PLAN«380)>) 


(<>) ) 


(TASK  (GATHERER  PLANtf3801  PRIMITIVE) 
(INFERENCES  MADE  BY  (GATHERER  PLAN«3801 
--) 

(RECORDING  (:REDUCED  (*DES*))  0) 
(♦INFERENCES  DONE*) 


{The  interpreter  uill  see  this  message  in  a second. 


(ENABLED  ((♦DES^M)  ' 
(FINISHED  (GATHERER  PLAN»380I) 


{Now  the  task  is  reat  tempter): 

(EXECUTING  ((♦DFS^n  (DESIGN  (LAMBDA  (X) 

(AND  (DEV-TYPE  ’X  AMPLIFIER) 

(-  (V-GAIN  ?X)  S) 

(-  (INPUT-Z  ?X)  30000)))! 

(<’ (WINNER)>1 ) 

(TASK  ((♦DES^))  ALREADY  REDUCED)  {The  /{REDUCED  formula  is  seen 
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(ENABLED  (T'ARB/1G91)) 
(ENABLED  (T'A00/21GAn 


;The  policies  are  pot  into  ft  feet: 

(EXECUTING  (T'A00/215A)  (D-NOIE  (RANGER  V-GAIN  MODERATE) ) 

(<>)  ) 

(TASK  [T'A00/215A]  BEING  REDUCED) 

(TASK  [TIA00/215A1  REDUCED  TO  [:PBIM  *SETUP) ) ' 

(EXECUTING  (TIA00/1GB1]  (D-NOTE  (RANGER  INPUT-Z  HIGH)) 

(<>)  ) 

(TASK  ITIA00/1G31)  BEING  REDUCED) 

(TASIC  IT'A00/1691)  REDUCED  TO  I:PRIM  *SETUP) ) 

;Recording  these  policies  causes  (mo  of  the  rules  inferred  above  to 

; fire... 

(ENABL  ED  (MAKER  (*0ES*n  ) 

(EXECUTING  (MAKER  (#DEG*I)  (MAKE  AMPLIFIER) 

(<•  (UINNER  (*DES»))>)  I 
(TASK  (MAKER  (*DES<t))  BEING  REDUCED) 


; . . . so  there  are  tuo  nays,  common  emitter  and  common  collector. 
; to  make  an  amplifier 
(MAKING  A CHOICE) 

(RECORDING  I: CHOICE  CHOlCEtf402  EXEC( 

I: TO-DO  (MAKER  (*0E5*) ) 

(MAKE  AMPLIFIER)  <’ (UINNER  (*DES*))> 

7UAY)) 

0) 

; The  system  records  first  the  choice,  then  the  options. 
;Recordi’ng  the  choice  causes  a flock  of  choice  rules  to  be 
; i ns  t an  t i a t ed: 

(RECORDING  (:GEN  (NOT  (:-  (MAKER  (*DES*))  ZAMP-TASK'^S) ) 

(AND  (CHOOSE-AMP-PKT  CHOICE»A02  ?AMP-TASK^3 

(MAKER  (»DES*))  (’(UINNER  ...))  (?UAY) ) 
(:GEN  (NOT  (: SCOPE  ’PTSK"3  ?AMP-TASK^3) ) 
TRUE))) 

0) 

; The  choice  rules  comp  in  a packet: 

(RECtJRDING  (CHDOGE-AMP-PKI  DIO1CE«402  (MAKER  (-kOES*) ) 

(MAKER  (*[IESkl] 

('(UINNER  (♦DCS*))) 

PUAY)  ) 

0) 

;This  odd-looking  formula  is  intended  to  trigger  antecedent 
; rules  in  the  packet  uhtch  uould  otherwise  not  be  noticed 
(RECORDING  1:GEN  (NOT  (:SC0PE  ?PTSK'A  (MAKER  (*0ES*) ) ) ) 

TRUE) 

0)  ' 

} ...  such  as  this  one: 

(RECORDING  (:ANTEC  (NOT  (:SC0PE  ’PTSKl  (MAKER  (*UES*)))) 

(:GEN  (NOT  (AND  (rPOLICY  ?PTSK1  (D-NOTE  LINEAR)) 
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(:SCOPE  7PTSK2  (HAKER  (*DES*))) 

(: POL  ICY  7PTSK2 

ID-NOTE  (RANGER  P-GAIN  HIGH))) 
{->  ’ (OEN  ...)  7PTSK2))) 

(:ANTEC  (NOT  (:OPTION  CHOICE«^02  7A1  [:T0-00  ...1)) 
(:GEN  (NOT  (OPT-SUPPORT  7A1  ...)) 

(:  RULE -TOGETHER  <?A1>  I:  TO-DO  ...JIM)) 

0) 

(RECORDING  (:SCOPE  T'A00/21GA  (MAKER  (*DES*m 
0) 

(RECORDING  [:SCOPE  T'400/1G31  (MAKER  (*OES*MI 
0) 


;Here  is  the  first  option 

(RECORDING  (-.OPTION  CHOI CEWA02  OPT«A03  (:TO-DO  (MAKER  (*DES*n 

(MAKE  AMPLIFIER) 

<•  (WINNER  (*DES*n> 

(MAKE  CCm 

0) 

; I t f i nds  a rule 

(RECORDING  (:ANTEC  (NOT  (:OPTION  CHOICEtfA02  ’Al 

(: TO-DO  (MAKER  (*OES*) I 
(MAKE  AMPLIFIER)  <_74N> 

(MAKE  74.DT1)))) 

(:GEN  (NOT  (OPT-SUPPORT  ?A1 

{.-POLICY  _?4PTASK  (D-NOTE  ...)))) 

(:ANTEC  (NOT  ( : OPT  I ON  CHOICE«A02  ’A2  I : (0-00  ...)M 
(:GEN  (-  ?A1  7A2)  (sRULE-TOGETffER  <7Al  ?A2> 

I: TO-DO  ...)))))) 

0) 

; and  chec)<9  the  support  for  (he  options  to  see  if  input  impedance 
; uas  relevant 

(RECORDING  (:GEN  (NOT  (OPT-SUPPORT  OPT«403 

(: POLICY  _?+PTASK^3 

(D-NOTE  (RANGER  INPUT-Z  _...))))) 
(:ANTEC  (NOT  (;OPTION  CHOICE«A02  7A2"3 

(: TO-DO  (MAKER  ...)  (MAKE  AMPLIFIER) 

<. . . > 

(MAKE  _...)])) 

(:GEN  (.  OPTtfA03  7A2^3) 

(iRUl  E- TOGETHER  <OPT<fA03  ?A2"3> 

ItTO-OO  (MAKER  ...)  (MAKE  AMPLIFIER)  <...> 
(MAKE  ...)l))n 

0)  ' 

1 1 1 uas 

(RECORDING  (:ANTEC  (NOT  (lOPTION  CHOICE»A02  7A2"A 

(iTO-00  (MAKER  (•DES*)I 
(MAKE  AMPLIFIER)  <*...> 

(MAKE  _?4-0T2‘'4M)) 

(:CEN  (-  OPT/Y403  ?A2''4) 

(: RULE -TOGETHER  <OPT«403  ?A2"4> 

(: TO-DO  (MAKER  (*OES*)( 

(MAKE  AMPLIFIER)  <'...> 
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9) 

(RECORDING  l:GEN  (- 


0) 


(tlAKE  (CASCADE  CC  _...()]))) 

OPT»A03  OPT«403)  (: RULE- TOGETHER  <OPTtf403  DPTtf403> 
(: TO-DO  (UAKER  (*DES*)) 

(DAKE  AUPLIFIER) 

<’ (WINNER  ...)> 

(MAKE  (CASCADE  CC  CC)))M 


;The  rule  excludes  cascading  something  with  itself,  so  this  line  of 
; inference  dies. 


;Here  is  the  seconrl  option: 

(RECORDING  (.-OPTION  CHOICIffAeZ  OPT;(f404 
I : TO-DO  (HAKER  (*DES*) ) 

(MAKE  AnPLIFIER)  <' (WINNER  (*0ES*))> 
(MAKE  CEIll 

0) 


;It  is  checked  for  input  impedance  being  relevant 
(RECORDING  (:GEN  (NOT  (0PT-5UPP0RT  OPT<(404  (:P0LICY  _?+PTA5K''3 

(D-NOTE  (RANGER  INI\IT-Z 

...mn 

(:ANTEC  (NOT  (:0PTI0N  CHOICE«402  ?A2^3 

(: TO-DO  (MAKER  ...I  (MAKE  AMPLIFIER) 


(MAKE  _...)))) 

(:GEN  (-  OPTtf404  ?A2''3)  (: RULE -TOGETHER  <OPT<(404 

?A2"3> 

[:T0-00  (MAKER  ...I 
(MAKE  AMPLIFIER) 


< . . . > 


(MAKE  ...)))))) 

0)  ! 

;It  isn’t.  However,  the  /.-ANTEC  derived  from  the  other  option 
; tr i gger 3, 


(RECORDING  (:GEN  (-  OPT//403  OPT#404) 

(: RULE -TOGETHER  <OPT«403  OPT)»404> 

I: TO-DO  (MAKER  (*DES*) ) 

(MAKE  AMPLIFIER)  <’ (WINNER  ...)> 
* (MAKE  (CASCADE  CC  CE))!)] 

0) 

; and  the  appropriate  cascade  is  suggested: 

(RECORDING  I .-RULE -TOGETHER  <OPT<(403  OPT«404> 

(:TO-On  (MAKER  (*OES*) ) (MAKE  AMPLIFIER) 

<• (WINNER  (*DES*))> 

(MAKE  (CASCADE  CC  CE)))I 

0)  ' 

(RECORDING  (:0PTI0N  CHOICE «402  NEWOPT«405 
I:TO-nO  (MAKER  (*DES*)) 

(MAKE  AMPLIFIER)  <’ (WINNER  (*DES*))> 
(MAKE  (CASCADE  CC  CE))1) 


0) 
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;Th'i5?  new  option  gops 
(RECORDING  [:GEN  (NOT 


(:  ANTEC 


througti  thp  mi  I I also 
(OPT-SUPPORT  NEUOPTffA05 
[:E’0LICY  _?+PTASK"3 

(D-NOTE  (RANGER  INPUT-Z  _...»)))) 

(NOT  (:0PTI0N  CHO1CE»402  ?A2"3 

(;T0-00  (MAKER  ...I  (MAKE  AMPLIFIER  I 


(MAKE  _...)))) 

(:GEN  (-  NEUOPTtfA05  ’A2^3) 

(: RULE-TOGETHER  <NEUOPT«A05  ?A2"3> 
(:T0-00  (MAKER  ...)  (MAKE  AMPLIFIER) 


0) 


< . . . > 

(MAKE  ...nmi 


;A  rather  unpromising  cascade  is  suggested: 

(RECORDING  (:GEN  (-  nPI«''(03  NEUOPTAA05) 

(:RULE-T0GLTHFR  <OPT«403  NEUOPTff40S> 

1: TO-DO  (MAKER  (*DES*) ) (MAKE  AMPLIFIER) 

<• (UINNER  . . . )> 

(MAKE  (CASCADE  CC  (CASCADE  CC  CE)))))1 

0) 

(RECORDING  (:RI)LE-Tf3GETI(ER  <OPT«A03  NEUOPT«A05> 

(: TO-DO  (MAKER  (*005*))  (MAKE  AMPLIFIER) 

<’(UINtJER  (*DES*))> 

(MAKE  (CASCADE  CC  (CASCADE  CC  CE))M) 

0) 

jbui  for  some  reason  vanishes.  (Notice  that  the  rule  should  he. 

; "If  X uas  suggested  because  of  its  input  impedance  and  g uasn’t, 

; cascade  them."  Then  this  cascade  would  never  have  been  suggested.) 


;The  / : RULE- TOGE THER  causes  the  old  options  to  be  flushed 
(FLUSHED  (:C0NSEQ  ( : OPT  I ON  CHOI CEtf402  OPTW404  (:T0-D0  (MAKER  (*DES*) ) 

(MAKE  AMPLIFIER) 

<• (UINNER  . . . ) > 

(MAKE  CE)I ) 

FALSE) ) 

(FLUSHED  hCONSEQ  ( :RULE-T0GETHER  <OPTff403  OPT«404> 

(:T04T0  (MAKER  (*DES*I ) 

(MAKE  AMPLIFIER) 

<■ (UINNER  . . . )> 

(MAKE  (CASCADE  CC  CE)M  ) 

FALSE) ) 

(FLUSHED  (tCONSEQ  (rOPTIDN  CHniC2tf402  DPT«403 

1:  TO-DO  (MAKER  (*[TES#)) 

(MAKE  AMPLIFIER)  <*  (UINNER  ...)> 

(MAKE  con 

FALSE) ) 

(FLUSHED  (:  ANTEC  (NOT  (:  OPT  I ON  CHOICE«402  ?A2^4 

[: TO-DO  (MAKER  (*0ES*) ) 

(MAKE  AMPLIFIER)  <’...> 

(MAKE  ?+DT2"4)))) 

(:GEN  (-  OPTW403 
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(:ni)ir-Tnr.nMER  <orti/a03  ’A2"^> 

(■.  ro  no  (MAKER  (*nE5*n 

(MAKE  AMPLIFIER! 

(MAKE  (CASCADE  CC  _...))))))) 

(FLUSHED  [:CnNSEQ  (: RULE -TOGETHER  <OPTtfA03  NEUOPT/K40S> 

(:Tn-nO  (MAKER  (*DES*)) 

(MAKE  AMPLIFIER!  <’(UINNER  ...!' 

(MAKE  (CASCADE  CC  (CASCADE  CC  CE ! ! ! ) ! 

FALSE) ! 

(CHOICE  CHniCE«40r  DONE! 

jThe  choice  successfully  reMuceri  the  design  problem: 

(TASK  (MAKER  (*nES*!]  REDUCED  TO  (MAKE  (CASCADE  CC  CEM! 

(CREATING  TASK  (:TA5I<:  G0.:A8  <>  (LAMBDA  NIL 

(MAKE  (CASCADE  CC  CEN! 

<'(UINN(.R  (*DES*!!>1! 

(NEU  TASK  (G02A81  HAS  ACTION  (MAKE  (CASCADE  CC  CE!1! 

(ENABLED  (G02A81! 

(EXECUTING  (G0E481  (MAKE  (CASCADE  CC  CE!) 

(<MUINNER  (*nES*!!^)! 

(TASK  (G0248)  BEING  REDUCED! 

: There  Is  a standarcl  plan  for  doing  cascades: 

(TASK  IG0248)  REDUCED  TO  (:D0-SUBNET  (CASCADE-PLAN  CC  CE! 

'CASCADE-NAME>n  ' 

(CREATING  TASK  (:TASK  (MAKER- 1 PLANK40G) 

<>  (LAMBDA  NIL  (MAKE  CC!! 

<• (FIRST -DEV  PLAN«40G)>)! 

(CREATING  TASK  (:TASK  (MAKi.R-2  PLANff40G! 

<>  (LAMBDA  NIL  (MAKE  CE!! 

<’  (SECDNI!-DEV  PLAN«40G!>] ) 

(CREATING  TASK  (:TASK  (GRABBER  PI  AN«40G!  <> 

(LAMBDA  NIL 

(GRABBA  (LAMBDA  (X! 

(MAIN-DEV-TYPE  ?X  (CASCADE  CC  CE!!!!! 

<’ (CASCADE -NAME  PL ANff40G! >) ! 

(CREATING  TASK  (:TASK  (COUPLER  PLAN»40G! 

<’(FIRST-DEV  PLAN/T40G!  ’ (SECOND -DEV  PLANtf40G!> 

(LAMBDA  (D1  02!  (COUPLE  ?D1  ?D2! ! 

<>]  ! ' 

At  this  point  a hm)  in  the  specification  for  the  cascade  plan  canserl  tlm 
system  to  crash.  (This  would  have  been  caught  by  a synta*  checker  of  Itm  kind 
I mentioned  a()Ove.  ! In  any  case,  the  system  currently  lacks  knoiiled(|»  nf 
common-collector  circuits  and  constraint  analysis,  so  it  could  not  tiav<>  yntie 
much  further. 


4 
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V.B.2  Converting  a Sctuare  Uave  into  a Sine  Have 


In  this  section  1 present  the  somewhat  more  disappointing  hetiavinr  nf  Or'il 

on  the  job  of  converting  a 1 kHz  square  wave  into  sine  wave  of  the  samo 

frequencg,  expressed  as  follows 

(des i gn 

(\  (ckt) 

( conver  t '^ck  t 
( \ (in) 

(and  (periodic  ( t fun  ?in)  1.0C-3) 

( f ot  a I I ( t ) 

( and  (implies  ( /<  ‘i’ t 0) 

(”  ((one-period  (tfun  ?in)l  ?t) 

in 

(implies  (not  (/<  ?t  0)1 

(«  ((one-period  (tfun  ?in))  ^t) 

-nn  n i 

( \ ( i n out ) 

(=  (tfun  ?out) 

(\  (t)  (sin  (*  2000  pi  ?t) ) ) ) ) ) n I 

< ’ ( f i I t nr  ) > 1 ) 

;The  initial  part  of  ttie  sequence  is  just  as  in  Sect.  V.B.l 
(CREATING  TASk 

itTAsic  (*nrs*)  x> 

(lAnOPA  Nil 

(DESIGN  UAnnpA  (CkT) 

(LDNvERi  ?CKT  (LAheOA  ...)  (LAnBDA  ...1)1)1 
<•  (FILTER)>)  ) I 
(ENABLED  ((*DES*)1) 

(EXECUTING  n*nrs* )]...) 

(TASK  n*nES*)]  RE  INC  prourro) 

(TASK  1(*DL5*)1  TO  PE  RE  PHRASED) 

(CREATING  TASK  ItTASK  'R( PHRASER  (*DES*)) 


(LAMpDA  NIL 

(:REPHRA5E  (*nES*)  lOESIGN  (LAnPDA  ...)1 
<• (FILTEH)>)) 

<>1  ) 

(ENABLED  (REF'HRASER  (*rtFS*)l) 

(EXECUTING  (REFWASFR  (»(IE5*I1 

1: REPHRASE  (♦DES*)  (DESK^N  (LAMBDA  (CKT) 

(CONVERT  ?CKT  (LAMBDA  ...) 
(LAMBDA  ...)))1 

(FILTER) >) 

(<>]  ) 

(TASK  IREPHRA5ER  (•DES*)!  BEING  REDUCED) 

(TASK  (REPMRASER  (•DES*))  REDUCED  TO 
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(:nn-SUHNt  T (Of  SI -Rf J'MRASF-PLAN 

(UAnnDA  (CKT)  (CONVERT  ...)))  (*nFS*)  '(FILIFRI) 
<>))  ' 


:I  tiavp  p I i ()p(l  I hp  mps«'..TriPs  regarrlinrj  sptfing  up  tlip  rpphraginc) 
: network.  (Theq  ar  (>  the  «;ame  as  for  the  precerling  example.  I 


(EXECUTING  (ACCOUNT -rnn  au.  PLANW3921 
(ACCOUNT -FOR  AIL-SUAROS 

((LAn(l(3A  (CkT)  (rONVTRT  ?CkT  U AORDA  ...)  (L.AnBOA  ...Om 
(<>)  ) 

(Task:  (account-for-ai  l pi  an«3S2)  reinc,  reoijcedi 

(TASK  (ACCOUNT-FOR-Al.L  PLAN//3321  REUOCED  TO  (:PRin  *5ETI)P]  I 
(ENABI  EO  (EXPLOOf  R PI.AN«J9ri ) ' 

(EXECUTING  (EXPUIOER  PI  «N«332) 

(D-EXPLOOF  (ILAhROA  (TKT)  (CONVERT  ?CKT  (LAnBDA  ...I  (LAORDA  ...Mil] 
(<>]  ) 

(TASK  lEXPLOOER  PLANtf3'T.:i  BEING  REDUCED) 


: Exp  I os  I on  tjpci'ms  as  he  fore... 

(lASX  [EXPLODER  PI  AN«302]  RFOUCED  TO  (.-INFER  ’ (D-SHARD  ( (LAMROA  ...) 

((LAFIRDA  ...II) 

<>)  ) 

(INFERENCES  OADF  RY  lEHPI ODER  PLAN«3921 
--) 

(RECORDING  (0-SHARD  ( (I  AOROA  (CICTI 

(CONVERT  ?CKT  (LAhROA  ...)  (LAMBDA  ...)M) 
niAMROA  (C)YI) 

(CONVERI  ?D^T  (LAMBDA  ...)  (LAMBDA  ...))))) 

0) 


;TTut  this  time  the  mam  shai  rl  is  too  hairg  to  he  hatitU  pri  hy  STP, 

; 90  a suhtask  is  set  up 

(RECORDING  (.-TASK  T1'379/23AA  <> 

(LAMROA  Nil  (CVT-EXPLODE  ( U AMBDA  ...))  ((LAMBDA  ...1)1) 
<>) 

0) 

(CREATING  TASIY  (:TA5X  T1I379/23AA  <> 

(LAMBOA  Nil  (CVT-EXPLODE  ((LAMROA  ...1) 

((LAMBDA  ...)))) 

<> ) ) 

(RECORDING  (:SUBTASX  T1 '379/2344  (EXPLODER  PLAN«392)I 
0) 

(RECORDING  (:MAIN  T1 '379/24  (EXPLODER  PL ANff392)) 

0) 

(The  same  rule  <*CONVERT-FXI’LOOE>  also  sets  up  a rule  to  infer 
; SIG-TRANS  d-sharrls  from  the  "signal  features"  that  fall  out 
; of  the  convert  explosion... 

(RECORDING  (:ANTFC  (NOT  (SIG-FEATIIRE  ( (I  AMRDA  ...)]  ( (I  AMROA  ...I) 

■>*FEATURE^47I  I 

(D-SHARO  ((LAMBDA  (CKT)  (CONVERT  ...ID 


V Ppsu I ♦ n 


1 n 


(UAnnnA  (Ckt)  (sig-trans  ckt 


B) 

(•INFERFNfFS  nflNF*) 


1 I ) 


;Uork  heging  on  this  siititasK 

(ENARIFD  m '173/23?An 
(EKECUTING  ni'379/23?G) 

(CVT-EKPLODE  t (LAMBDA  (IN)  (AND  (PERIODIC  ...  0.001) 

(FORALL  ...)))) 

((LAMBDA  (IN  OUT)  (.  (TFUN  ...)  (LAMBDA  ...))))) 

(<>))  ' 

(TASK  (T1 '373/23361  BEING  REDUCED) 


;But  there  is  a choice  uhether  to  look  for  f requencg-doma i n 
; or  time-domain  feafures  of  the  signals 
(MAKING  A CHOICE) 

(RECORDING  (iCHOlCE  CHOirE«A10  EKEC 
I: TO-DO  T1 '373/4711 

(CVT-EKPLODE  (...)  1...1)  <> 

7UAY] ) 

0) 

(RECORDING  (:ANTEC  (NOT  (:OPTION  CHOICEWAIB  ’Al''3 

1: TO-DO  T1 '373/4711  (CVT-EXPLOOE  ...I 


(FREO-OOMAIN-REPHRASE  ...)))) 
(:ANTEC  (NOT  (:0PT10N  CHOICE «410  ?A2''3 
1:T0-UU  ...))) 

(AND  (:GEN  (NOT  (AND  ...))  (: ROLE- IN  ’ArO)) 
(:GEN  (NOT  (AND  ...))  (:RULE-IN 
(:GEN  (NOT  (AND  ...)) 

(:RUl E-OUT  ?A2"3))))1 


0) 

(RECORDING  (:OPT|ON  CHO1CEW410  0PT»411  (: TO-DO  T 1 ' 373/471  1 

(CVT-EKPLODE  (...) 


(...)) 


(TIME -DOMAIN -REPHRASE  (...) 
' (...)))) 

0) 

(RECORDING  (:OPT(ON  CHOICEff410  0PTtf412  (;TO-DO  Tl'373/4711 

(CVT-EKPLODE  (...) 

(...)) 


< > 

(FREQ -DUMA IN -RE PHRASE  (.  . . ) 

(...)))) 


0) 

(RECORDING  (:ANTEC  (NOT  (:OPT|ON  CHOICE»410  ’A2''S 

(: TO-DO  Tl'373/4711  (CVT-EKPLODE  ...) 


(TIME -DOMAIN -REPHRASE  ...)))) 
(AND  (:GEN  (NOT  (AND  (:-  ...I  (NOT  ...))) 
(:RULE-IN  OPT0412)) 

(:GEN  (NOT  (AND  (i-  ...)  (NOT  ...))) 


V Rrc.u  I t n 


1 /U 


0) 


(: RULE- IN  ’A2"5I) 

(:GFN  (NOT  (AND  (: SUBTASK  ...)  (: TASK-ACT  I ON  ...I 
(:=.  ...  ACTIVE) 

(D-FEATURE  ...)l) 

(:  RULE -OUT  ?A2''S)))1 


: Thp  choicp  rlpppnfl‘1  upon  uh.it  the  s i gna  I -descr  i p t i on  predicates 
: detiend  on.  (See  <*CV  T-CUI!)  I CE>  in  Appendix  3.) 

(RECORDING  (:GEN  (NOT  (AND  (:-  I...)  [...))  (NOT  (CONTAINS  ?+FTODY^G 

...)))) 


(:R1JLE-IN  0PTA412)) 


0)  III 


: Fr  equpncg-rioma  i n is  indicated-- 
(RECOROING  (:TTULE-IN  0PTffA12l  0) 


(RECORDING  (:GEN  (NOT  (AND  (:-  (...)  [...))  (NOT  (CONTAINS  t>4B0DY% 

. . . I ) n 


(:RULE-IN  OPTtfAllM 

0)  I M I M M 

The  /:GEN  fount)  nothing  in  this  case,  so  time  domain  gets  no 
votes. 

(Checking  CONIAINment  took  a long  time,  as  the  row  of  " i ' s" 
attests.  This  is  a tgpic.it  example  of  the  slouness  of  STP 
on  a straight  foruard  prolUem  in  which  it  did  absolutely  no 
combinatorial  search.) 


;This  rule  also  ended  up  with  nothing: 

(RECORDING  (:GEN  (NOT  (AND  (:SUBTASK  (DEN  ,..)  ?SUP"G) 

(:  task-action  ’SUP^G  (O-EXPLODE  ?4P''GM 
(!’  (:ENAB-STATUS  ?SUP^) 

. ACTIVE) 

(0  FEATURE  (RANGER  FREQ-OP  VERY-HIGH)))) 

(: RULE-OUT  OPTWAID) 

0) 


I 


•,So  thp  vote  for  frpr|uency-rlomain  is  decisive... 

(CHOICE  CHOICEtfAlB  DONE) 

(TASK  (T1  I373/230S1  REDIITJO  TO 
(FRltJ-DOUAIN  FTF  PHRASE 

((lAUBOA  (IN)  (AND  (PERIODIC  ...  0.001)  (FORALL  ...)))) 

((LAnODA  (IN  OUT)  (-  (TFUN  ...)  (LAMBDA  ...)))))) 

; . . . ant)  execution  proceeds 

(CREATING  TASK  (;TA5K  G0,'A1  <>  (LAMBOA  NIL 

( FREQ -DOMAIN -RE (’HR ASE  ( (LAMBDA  . . . ) 1 
((LAMBDA  ...)))) 


<>I  ) 


(ENADirn  (f,02AlI) 

(EXECUTING  (G02A1)...) 

(TASK  (G0.'A1)  HEIN(.  REDUCED)  i 
(TASK  (G02A11  REDUCED  TO 

(:SE(]  (:FIND  (LAMBDA  (»EPT) 


L 
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(EXISTS  (FPl  FP2  FPT) 

(FORALL  (SI  S2)  (inPLIES  ...))))) 

(LAMBDA  (FPT)  (:1I^FER  ’ (SIG-FEATURE  ...I  <>))]) 

;The  plan  is  to  find  freciuency  pictures  and  compare  them..,, 

(CREATING  TASK  (:TASK  ITASK//4U  <>  (LAMBDA  NIL 

(:FIND  (LAMBDA  (+FPT) 

(EXISTS  (FPl  FP2  FPT) 
(FORALL  ...))))) 


<’ (FPTtf413)>l) 


; . . . then  infer  signal  features.  (See  <*FREQ-D0M-REPH-D0-1 >. ) 
(CREATING  TASK  (:TASK  MTASK«423  <’(FPTtf413)> 

(LAMBDA  (FPT) 

(: INFER  ’ (SIG-FEATURE  ...) 

<>) ) 

<>)  ) 

(ENABLED  (ITASK»414])  ' 


(BLOCKED  (MTASKff4231  ) 
(EXECUTING  (I TASK«4141  . . . ) 
(TASK  nTASK«414)  PRIMITIVE) 


;/:FIND  is  the  user’s  way  of  calling  STP, 

;Here  is  what  the  STP  tra'e  loo)<.s  lil^e  for  this  problem: 

(STP  TRACE  1 0 (NOT  (IMPLIES  (AND  (IS  SIGNAL  SI >433/3330) 

(AND  (PERIODIC  (TFUN  ...) 

0.001) 

(AND  (IMPLIES  ...)  (IMPLIES  ...))) 
(IS  SIGNAL  S2>434/3330) 

(>  (TFUN  S2'434/3330) 

(LAMBDA  (T) 

(SIN  ,..)))) 

(AND  (»>  ’ (FREQ-PICTURE  . . . ) 

?FP1) 

(->  ’(FREQ-PICTURE  ...)  ?FP2) 

(FREQ-PIC-TRANS  ?FP1  ?FP2 
?FPT) 

(->  ’ (DEN  ,..)  ?FPT)))1 

NIL)  "" 

Unfortunately,  a bug  in  a very  low-level  routine  caused  an  infinite 


recursion  in  the  midst  of  this  attempted  proof.  Therefore,  the  system  novrr 
got  to  the  point  of  actually  generating  or  comparing  frequency  pictures. 
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V.B.3  NOAH  in  NASL 

Jon  Doyle  and  I have  done  some  preliminary  experiments  toward  a "free 
translation"  of  Earl  Sacerdoti’s  (1975)  NOAH  program  into  NASL.  As  I 
discussed  in  Chapter  1,  NOAH  and  NASL  are  based  on  rather  different 
presuppositions,  so  an  exact  translation  would  be  somewhat  contrived.  NOAH  is 
organized  around  repetitive  execution  of  a strict  sequence  of  steps  of  the 
form,  "Expand  the  plan;  criticize  it."  After  the  plan  has  been  entiretu 
reduced  to  primitives,  it  is  executed.  In  carrying  out  these  steps,  the  NOAH 
system  assumes  that  all  actions'  effects  are  fully  computable  in  advance;  it 
reasons  confidently  about  future  states  of  the  world.  This  assumption  is 
false  for  many  of  the  actions  NASL  tries  to  accomplish. 

Nonetheless,  the  parallels  between  the  two  systems  are  tempting.  Up 
wondered  if  it  was  possible  to  encode  NOAH  "critics"  as  NASL  "policies."  The 
critics  we  concentrated  on  were  "Resolve  Conflicts,"  which  orders  actions  to 
prevent  one  from  undoing  the  prereques i tes  of  another;  and  "Eliminate 
Redundant  Preconditions,"  which  attempts  to  prevent  the  same  action  being  done 
twice  for  two  different  reasons, 

Ue  have  done  some  preliminary  coding  (it  only  takes  about  5 pages  of  NASL 
expressions),  hut  the  unsettled  state  of  the  interpreter  has  made  this  mainly 
a Gedanken  experiment.  The  results  so  far  are  mixed.  On  the  one  hanil,  it 
takes  very  little  effort  to  express  as  deductive  "mini -theor ies"  murh  of  what 
is  meant  by  concepts  like  "prerequisite"  in  a system  like  Sacerdoti's  iihirh 
has  them  built  in. 

On  the  other  hanri,  ue  tiad  some  disappointments.  It  is  more  difficult  than 
I had  hoped  to  distinguish  problem  reduction  from  execution,  NA5L  asr.unies 
that  a network  can  be  executed  as  soon  as  it  is  generated;  to  force  it  to  he 
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more  NOAH- I ike  requires  the  user  to  write  explicitly  the  theory  of  I ntmr  n t i on 
levels  that  is  apparently  built  into  the  NOAH  e I aborate-cr i t i c i ?e  loop.  Tfip 
user  must  explicitly  tell  the  system  to  postpone  execution  of  lower  levels 
until  higher  levels  are  reduced.  In  principle,  there  is  nothing  iironr|  iiifh 
having  to  do  this,  since  this  is  just  another  mini-theory.  Uhat  marie  us  a bit 
squeamish  about  it  was  the  necessity  of  ignoring  altogether  NASL’s  use  of 
/:MAIN  tasks  (Sect.  II. 0.1)  in  specifying  what  happens  during  task  rerluction, 
and  replacing  it  with  an  explicit  theory  of  /iSUCCESSOR  relations. 

I think  it  is  fair  to  conclude  from  this  "experiment"  that  NASL  is  ,sn 
worthwhile  alternative  to  NOAH,  especially  for  problems  where  there  is  much 
user-supplied  knowledge  about  plans,  and  only  incomplete  foreknowledge  n1  the 
effects  of  the  basic  actions. 
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VI  Conclusions 

"This  ...  may  seem  trivial, 
but  1 think  it  is  not  without  importance." 

— Mary  Uarnock,  Ethics  since  1900 

I set  out  to  construct  a circuit  designer  so  flexibly  organizer!  ttia)  It 
could  respond  to  all  relevant  aspects  of  a design  problem,  yet  directerl  ennugh 
to  be  efficient  during  its  normal  operation.  1 implemented  a rule-basnti 
problem  solver  called  NA5L  and  have  done  preliminary  experiments  using  as  my 
main  vehicle  DESl  and  ZORCH,  sets  of  rules  embodying  theories  of  rlesign  and 
electronics.  The  results  are  consistent  with  the  hypothesis  that  the 
organization  of  NASL  has  the  right  kinds  of  power.  As  with  many  experiments 
in  AI  , the  results  are  not  unequivocal.  Our  conclusions  rest  largely  on 
esthetic  considerations. 

The  theories  of  design  and  electronics  drew  heavily  on  previous  work  hy 
others.  (Freeman  and  Newell,  1971,  Stallman  and  Sussman,  197G,  A.  Broun,  197S) 
There  are  novel  elements.  The  design  process  embodies  a modified  top-doun 
strategy.  Domain-dependent  information,  expressed  in  a modular  way,  nrdors 
design  choices  and  controls  their  interaction,  Uhen  the  top-down  elahnr.ition 
reaches  the  level  of  canned  "device  schemata,"  the  task  structures  stored 
there  become  integrated  with  it.  The  theories  embodied  in  the  programs  that 
make  this  happen  are  further  steps  toward  competing  with  human  per foi  mance  in 
these  areas. 

NASL  has  severe  limitations.  Due  to  limited  time,  I was  unati  I e to  develop 
many  doma i n- i ndependent  control  features,  because  they  were  not  neerled  tor 
electronic  design.  (Some  of  these  limits  were  encountered  in  our  attempt  to 
study  NOAH  with  NASL.  See  Chapter  V.)  The  logics  of  time  and  belief  are 
practically  absent.  Hence.  I cannot  claim  that  the  current  system 
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just  as  easily  used,  e,g.,  to  understand  stories.  Even  some  featijrps 
important  to  electronic  design,  such  as  describing  and  correcting  mistikps. 
could  not  be  implemented  in  the  time  I had. 

Second,  the  system’s  flexibility  in  principle  is  offset  by  its  lark  of 
patience  and  skepticism  in  assimilating  uhat  it  hears.  An  untrainerl  iispr 
could  bring  its  operation  to  a halt  by  telling  it  the  wrong  things. 

I have  had  some  disappointing  failures.  The  program  is  too  big  .ami  slow 
to  be  practical,  apparently  because  of  the  implementation  of  data-h.)sp 
operations,  rather  than  because  of  any  combinatorial  explosion.  Horp 
substantively,  the  division  of  labor  between  theorem  prover  and  Interprotor  is 
in  many  ways  wrong.  The  decision  to  use  predicate  calculus  for  representing 
and  using  knowledge  was  the  major  theoretical  gamble  in  NASL’s  design.  Ttiis 
gamble  has  had  wildly  equivocal  results. 

The  style  of  knowledge  encoding  encouraged  by  NASL  is,  in  my  opinion, 
quite  exciting.  These  features  in  particular  stand  out: 

> All  control  information  is  explicitly  represented  in  the  data  hasp. 

> Host  dependency  information  is  automatically  gathered  by  the  system  in  a 
complete  and  convenient  way. 

> Plans  can  be  described  incrementally.  Specification  of  crder  anri  choice 
depends  on  rules  which  can  be  combined  in  flexible  ways. 

> Predicate  calculus  is  used  as  the  notation  for  control  and  physical 
informat  ion. 

I will  discuss  first  my  successes,  then  my  failures,  and  which  way 
research  might  go  to  overcome  the  limitations  I have  discovered. 
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VI . A Successes 


In  this  section  1 want  to  put  the  NASL  system  in  perspective,  anti  arr|ijo 
that  it  is  a step  toward  understanding  mental  functions.  Fig.  VI. 1 shniis  a 
map  of  current  ar t i f i c i a I - i nte I I i genca  research.  It  may  also  he  taken  as  a 
map  of  mental  functions,  with  the  arrows  taken  as  indicating  the  flow  of 
information.  Either  way,  the  central  box  with  the  question  mark  Is  a major 
mystery.  Ue  know  that  this  center  is  concerned  with  "unrf.rs  t and  i ny , " "prolilem 
solving,"  and  "learning,"  and  we  know  that  it  contains  many  suh-hoxes.  finch 
of  mainstream  AI  is  concerned  with  the  somewhat  speculative  pastime  of 
proposing  and  testing  pieces  of  this  box. 


<r 
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Figure  VI,1  Provinces  of  Artificial  Intelligence 
The  thesis  that  rule-driven  problem  solving  is  an  important  techniquf* 
depends,  I think,  on  a picture  of  the  mystery  box  like  that  of  Fig.  VI. 2. 
Normal  cogitation  is  performed  by  a problem  solver  accessing  a data  base  of 
rules.  Neu  rules  are  created  by  a rule  generator;  the  most  direct  nay  is  hy 
translation  from  natural  - 1 anguage  statements.  The  rules  are  not  guaranippd 
"correct”:  they  must  be  revised  if  faulty  by  a debugger.  (McDermott.  lD7i'»a, 
Sussman,  1975) 


i 
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Vision 


Hearing 


L I 


Figure  VI. 2 The  Rule-Based  Utopia 

To  some  degree,  putting  these  last  two  functions  in  neat  boxes  is  uishlul 
doodling,  but  the  problem-solver  box  is  intended  to  be  real.  The  NA'iL  si)stem, 
or  some  future  descendent,  resides  in  this  box.  To  what  degree  do  features  of 
NASL  support  progress  on  the  rule-driven  paradigm?  In  answering  this 
question,  ’ will  survey  in  detail  what  I consider  the  strengttis  of  tl'e  cm  rent 
system, 

NASL  is  driven  by  a general  predicate  calculus  that  supports  hacl'iiarri  .mcl 
forward  deduction.  This  feature  forces  the  user  to  think  in  terms  of  truth 
and  falsehood,  rather  than  m terms  of,  e.g.,  "demonic  action."  For  ex.im|ile 
(see  Chapter  II),  there  is  no  way  to  "deduce  the  erasure"  of  a formula. 

Unlike  a PLANNER-type  system  (Hewitt,  1972),  NASL  treats  erasure  entirely 
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differently  from  recording.  This  enables  more  revealing  records  to  tie  kept. 

It  forces  the  user  to  think  in  terms  of  true  rules  rather  than  apiiarently 
useful  ones,  like  productions,  uhich  might  have  to  be  changed  later,  or  might 
introduce  arbitrary  symbols  with  no  presumed  meaning,  (Rychener,  197R,  Neue I I , 
1971)  This  half  of  llinsky’s  (1974)  "monotonicity"  problem  is  no  problem  .at 
all,  but  a valuable  kind  of  discipline. 

The  notational  power  of  the  predicate  calculus  %tr ikes  me  as  a tool  we 
cannot  do  without.  Much  of  this  power  depends  on  providing  a good  voc-abulary; 
and,  in  the  realm  of  control  structure,  I have  done  this.  But  the  not-ation 
itself  is  good,  in  my  experience,  independently  of  what  it  is  talking  .about. 

It  allows  you  to  think  in  terms  of  statements  with  truth  values.  Its  tre.atment 
of  quantifiers  doesn't  cramp  your  style,  it  provides  powerful  and  natural 
pattern  matching,  and  it  forces  ^ou  to  say  what  you  mean. 

This  formal  freedom  is  necessary  to  to  support  restrictions  on  ttie 
substance  cf  rules.  NASL  formulas  are  not  restricted  to  talking  about 
clinical  parameters  or  values  of  physical  quantities  in  a network,  but  ttirg 
are  restricted  (for  practical  purposes)  in  the  way  they  talk  about  conrepts 
like  action,  decision,  policy,  and  problem  transformation.  In  orrler  to  ciet 
something  done  in  NASL,  you  must  express  yourself  in  terms  of  tasks,  "rule- ins 
and  rule-outs,"  rephrasing  actions,  etc.  The  task  language  is  restricterl  to 
such  a degree  (there  being  no  real  loops,  gotos,  or  conditionals)  that  many 
things  can  be  done  only  via  these  mechanisms. 

These  conventions  enforce  "intelligibility"  at  a useful  level.  At  nvrry 
step,  the  system  knows  by  way  of  quite  shallow  deductions  almost  everything 
there  is  to  know  about  what  it  is  doing,  what  its  future  tasks  are,  why  it 
chose  to  do  what  it  did,  etc.  This  knowledge  is  used  heavily  in  the  rulp'i  for 
choosing,  rephrasing,  and  mistake  correction.  Because  the  number  of  innate 
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concepts  has  deliberately  been  alloued  to  grou,  shallow  deduction‘s  arr- 
possible  and  required;  NASL  does  not  have  or  need  a theory  of  "program 
understanding."  (Ualdinger  and  Levitt,  1974)  I believe  this  property  is 
essential  to  an  intelligent  program;  it  is  no  accident  that  the  average  person 
is  a good  planner  and  a bad  programmer. 

A most  important  example  of  this  reliance  on  innate  control  concepts  is 
the  notion  of  "frozen  tasks"  which  is  so  useful  in  the  representation  of 
device  schemata.  (Chapter  III)  The  instantiation  of  such  a schema  causes 
information  regarding  the  purposes  of  components  to  be  activatetl.  in  the  samp 
notation  that  is  used  for  expressing  explicit  goals.  These  old  tasks  ttien 
interact  with  new  ones  in  determing  the  solution.  In  this  way,  DESI  exhibits 
"mach  i nomorph  i sm. " The  purpose  of  a circuit  is  expressed  as  a frozen  purpose 
of  the  machine.  No  new  concept  needs  to  be  introduced,  and  the  problem  of 
relating  the  special-purpose  teleology  of  each  domain  to  the  machine's  concept 
of  its  own  purposes  is  avoided. 

This  organization  of  predicate  calculus  plus  large  innate  vocabularg  is 
potentially  of  great  value  to  the  Rule  Debugger  module  of  Fig.  V|.Z.  It  is 
known  that  debugging  a data  base  requires  keeping  records  of  the  use  of  data 
which  might  be  faulty.  (McDermott,  1974a,  Davis,  197G)  The  kinds  of  records 
kept  by  NASL,  deductive  dependencies  and  task  relations,  are  just  the  kinrls 
r equ i r ed. 

Another  powerful  organization  principle  that  emerged  during  flits  rp‘;r>.irch 
was  the  notion  of  "packet."  (McDermott,  1975)  This  device  enables  NASI  to 
represent  large  chunks  of  tiafa  at  a relatively  low  cost.  It  is  uieri  to 
represent  circuit  diagrams  and  sets  of  related  problem-solving  rules. 

From  a distance,  a packet  looks  like  a large  chunk  of  knowledrie;  up  rinse, 
it  looks  like  many  small  (lieces  of  knowledge.  It  may  be  used  to  im|ilrmi’til 
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"frames"  (Minsky,  1974)  in  an  "extensible"  uay.  The  knoulertge  is  orcianiznl  hy 
the  dependencies  I described  before,  but  a new  piece  of  knowledge  can  aliiays 
be  added  without  immediate  fear  of  interactions. 

This  is  partly  because  NASL  is  organized  around  the  expectation  of 
interactions.  It  expects  that  occasionally  more  than  one  or  less  than  one 
rule  will  appear  relevant.  In  these  circumstances,  it  enters  special 
protocols  which  first  look  for  relevant  higher-level  rules,  and  then  ark  ttm 
user  to  supply  them.  Much  remains  to  be  done  in  this  area.  (Good  work  has 
been  done  already  by  Davis  (197G).)  The  results  so  far  indicate  ttiat  tho 
standard  feeling  that  frames’  contents  are  hopelessly  "strongly  coiiplerC'  (cf. 
Sussman,  1975)  is  too  pessimistic. 

The  fact  that  NASL’s  facts  come  in  large  chunks  of  small  data  has 
implications  for  the  design  of  the  Rule  Generator  of  Fig.  VI. 2.  It  i s a very 
appealing  model  of  learning  by  discovery  that  large  bites  of  information  are 
taken  at  one  time,  by  coijying  an  entire  theory  from  one  domain  to  anofhot  . 
(Minsky,  in  progress)  Uhat  is  nice  about  rule-based  theories  in  pat  lirnlar  is 
that  they  hint  at  the  next  step:  altering  particular  rules  that  were  faultily 
transformed  during  the  "copy,"  and  adding  domain-specific  interaction 
hand  I er 9. 

The  kind  of  chunking  that  NASL  currently  supports  would  not  hanri  I e this 
kind  of  learning,  but  it  is  suggestive.  It  might  be  worth  making  the  effort 
to  recast  the  entire  corpus  of  electronics  information  as  an  i ns  I an  t i a t : on  of 
a more  abstract  (and  smaller)  theory  of.  say,  common-sense  physics.  If  this 
were  successful,  a start  at  capturing  any  similar  domain  would  he  to 
r e i ns  t an  t i a t e this  theory  In  a different  way. 

The  conclusions  I have  drawn  so  far  can  be  summarized  as  follows:  (1)  A 

flexible  problem  solver  must  have  innate  concepts  of  tasks,  derisions,  and 
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other  similar  control  concepts:  (2)  predicate  calculus  is,  at  present,  fl)P 
best  I anguage  for  CKpression  of  propositions  in  these  terms;  (3)  the  rules 
expressed  in  the  calculus  must  be  tightly  organized,  linked  by  depenrlenc  i es 
and  bundled  into  packets. 

VI ,B  Fai lures 

The  next  questions  are  somewhat  independent:  Is  a pred i ca te-ca I cu I us 

theorem  prover  an  effective  mechanism  for  retrieval  of  information  expressed 
this  uay?  In  particular,  can  it  be  interfaced  effectively  with  the 
interpreter  that  uses  It  to  decide  how  to  act?  With  respect  to  these 
questions,  the  cuf  ' it  version  of  NA5L  fails  to  provide  satisfying  ansuers. 

As  it  stands  now,  NASL  Is  organized  as  follows.  (See  Fig.  1. 9.)  Cnnirnl 
resides  in  the  Interpreter,  which  decides  what  to  do  and  how  to  :to  it  on  tlie 
basis  of  (a)  forward  deduction  triggered  by  plan  and  model  assertions  in  t tie 
data  pool;  (b)  backward  deduction  to  find  ways  of  breaking  prolilems  down  .inti 
to  answer  questions  in  the  domain  of  interest;  (c)  calls  to  the  choice 
protocol,  which  consists  of  a ritual  of  deductions  regarding  which 
alternatives  are  good  and  which  bad;  and  (d)  calls  to  itself  recursively  with 
/rREPHRASE  tasks  (which  are  restricted  to  being  inferential).  The  outstanding 
features  of  this  organization  are: 

(1)  The  action  system  always  calls  the  theorem  prover,  never  vice  vei  sa. 

(2)  The  system  contains,  in  effect,  two  independent  interpreters,  one  fnr 
plans,  and  one  for  implications  (/:C0('I5EQ’ s and  /:ANTEC’s). 

These  features  distinguish  NA5L  rather  sharply  from  the  typical  A1  I angi  lages . 
(Bobrow  and  Raphael,  1974) 

The  strengths  of  this  organization  are  easy  to  see.  The  two  i n t et  |u  e t er  s 
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are  optimized  separately.  For  example,  the  theorem  proven  doeq  not  tiavo  *o 
worry  about  side  effects,  so  it  can  re-order  conjunctive  goals  anri  ‘U'p.ir  ito 
goals  into  classes  which  share  variables  for  backtracking  purposes.  (her- 
Appendix  A.)  The  interpreter,  on  the  other  hand,  does  no  Ijack  track  i nr|  .it  all; 
handling  a failed  action  is  a problem  for  the  interpreter,  not  part  of  its 
solution  mechanism.  It  goes  to  great  trouble  to  find  reasons  for  its  rfioireri. 
rather  than  just  trying  cne  alternative  now,  and  another  later  if  that  one 
f a i Is. 

These  strengths  are  pleasing,  but  they  do  not  outweigh  the  weak  nos<-.os . 
which  are: 

(1)  The  same  knowledge  must  sometimes  be  put  in  two  places,  in  two 
notations,  one  for  each  interpreter. 

(2)  The  derluction  machinery  is  unable  to  use  information  about  chnlrn  ,mtl 
rephr as i ng. 

13)  Additivity  suffers  from  the  user's  uncertainty  about  which  inter  pt'-ler 
to  use.  If  he  guesses  wrong,  he  may  have  to  reorganize  his  data  rompleielti 
when  the  chickens  come  home  to  roost. 

Consider,  for  example,  the  notion  of  equation  solving.  DFSI  has  a weak 
ability  to  do  this  (see  Appendix  2 and  Chapter  III),  which  could  Ire  strnnri'-t 
without  too  much  effort.  Notice  that  this  information  has  been  expt  esreri 
an  "inferential  plan"  concerned  with  rephrasing  manipulations  of  prediiafo't  on 
constrained  riuantities.  This  seems  entirely  proper,  clear,  and  elegant.  Now 
consider  the  following  fleriuc  t i ve  goal: 

I-  (♦  ’X  3)  5) 

Plainly,  this  ref)uires  exactly  the  same  knowledge.  (Cf.  Brindy,  I'lTTrl 

It  woulf)  he  emliar  r ass  i ru)  enough  to  have  to  put  the  same  infnrm.it  inn  in  two 
places,  but  in  f.ict  ttie  situation  is  even  worse:  the  necessary  knowlediin 

cannot  be  (jivr.i  to  5)P  at  all'  (Uhich  is  why  it  appe.ir  s in  an  inferr.nti.il 
rephrasing  plan.)  It  would  have  to  be  put  into  an  ad  hoc  I ITP  program. 
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Rather  than  do  this,  1 have  tried  to  make  sure  that  deductive  goals  nl  this 
sort  never  appear.  The  absence  of  a choice  protocol  insirle  the  theornm  pr over 
hurts  just  as  much.  The  most  embarrassing  conseguenct  of  this  auk  iiat  dnoso  is 
that  the  user  must  plan  his  advice  a little  more  carefully  than  is  rk's  i i ah  I e ; 
he  must  decide  uhat  should  be  expressed  as  a task  and  what  should  be  expresserl 
as  a deductive  goal  on  the  basis  of  his  knowledge  of  the  theorem  prover's 
limitations;  this  reguires  an  unacceptable  degree  of  knowledge  of  the 
program’ 9 infernal  structure. 

This  problem  evolved  from  seemingly  innocuous  beginnings:  uhat  star  tnr|  as 
a single  interpreter  fissioned.  !t  has  been  clear  from  the  start  nf  this  uork 
(flcOermott,  1974b)  that  the  concepts  of  deduction  and  action  were  both  (jning 
to  be  necessary.  As  design  and  i mp  lemen  fa  t ion  proceeded,  these  Uia  rntr^rinr  ies 
became  more  and  more  closely  Identified  with  the  independent  cateynr  ie<i  nf 
"blind  search”  and  "careful  mode."  respectively.  The  theorem  prover  uas 
written  with  fewer  and  fewer  "careful"  features,  and  more  and  more  gennfal 
optimization  of  the  sort  described  above,  while  the  action  system  abrm  imfi  the 
cleverness.  This  organization  finally  broke  down  when  I realized  tliat  rnvnr.al 
sorts  of  "clever"  forward  deduction,  such  as  constraint  resolution  (h f a I I mati 
and  Sussman,  19761,  would  not  fit  into  the  framework  of  a stupid  fheot  em 
prover  (STP) . The  inferential  plan  was  created  to  fill  this  yap.  It  niag  turn 
out  to  be  the  right  solution  (see  below),  but  if  it  does  it  will  bp  an 
acc i dent . 

To  some  rlecjree  this  failure  is  due  to  sloppy  thinking,  tiut  ( Imlievn  iin. 
problem  is  more  f unriampn  t a I . The  only  way  to  make  "careful  mode"  wm  w • 

spend  time  asking  and  telling  yourself  uhat  you’re  doing.  If  tfi'  a > 
telling  is  itself  "rareful,"  things  become  i n t o I er  lb  I y si  uj . 

It  might  look  as  if  asking  and  telling  could  lie  pofenfia  '» 
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the  sense  that  they  could  normally  proceed  blindly,  but,  if  trouble  ariros, 
turn  themselves  into  ongoing  p I an- 1 anguage  plans.  For  example,  uith  thf* 
conjunctive  goal  (AND  (P  ?XI  IQ  ?X)1,  if  the  system  "runs  into  trouble"  on  IQ 
?X]  , it  could  turn  itself  into  a plan  of  the  form  "Find  a P;  then  verify  it  is 
a Q,  " and  use  choice  and  rephrasing  on  the  second  subtask.  There  are  tuo 
problems  with  this.  First,  it  is  not  all  that  easy  to  decide  that  you’re  in 
trouble.  The  mere  retrieval  of  tuo  rules  does  not  mean  that  a choice  is  in 
order;  the  tuo  rules  could  be  functioning  as  a CONO,  or  there  may  be  no 
intelligent  criterion  for  selecting  one  or  the  other.  Indeed,  once  one  has 
the  notion  that  the  theorem  prover  is  the  locus  of  "blind  search,"  he  lenrls  to 
write  rule  systems  of  just  this  sort.  Houever,  I believe  that  the  "me  t a-r  li  I e" 
construct  of  (1YC1N  (Davis  et.  si.,  1975)  would  go  far  toward  solving  this 
problem  cheaply. 

Second,  and  much  more  difficult,  is  that  the  kind  of  sequencing  flone  in  a 
backtracking  theorem  prover  is  just  not  the  same  as  that  in  a planner. 
Predicate  calculus  is  a non-deterministic  language;  it  does  no  good  to 
translate  it  into  a formally  isomorphic  construction  in  a deterministic 
language.  Put  another  way,  NASL  is  intelligible  because  many  unintelligible 
constructs  have  been  covered  by  deduction  or  other  built-in  protocols:  "map" 

loops  like  those  in  LISP  are  done  by  generating  items  deductiveh)  and 
generating  a (sub)  task  for  each;  many  search  loops  are  done  by  finding  nn» 
such  I tern;  the  choice  protocol  Is  a priceless  piece  of  "canned  loop"  which 
replaces  specialized  discrimination  nets.  To  ask  that  any  of  these  constructs 
be  translatable  when  necessary  into  NASL  plans  Is  to  destroy  this 
Intel  I igibi I i ty. 

The  situation  is  not  hopeless;  I have  just  learned  less  about  this  aspect 
than  I had  hoped.  Here  are  two  possible  routes  for  avoiding  this  prol'lem: 
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(1)  Elevate  this  rli sorqani zat ion  to  the  status  of  a theoretical  cnnjnrture 
that  "deductive  information  retrieval"  is  a separable  activity  that  novnr 
requires  anything  as  complicated  as  solving  an  equation  or  rephrasing  a r|oal. 
(This  is  part  of  uhat  R.  floore  11975)  and  Fahiman  (1975)  have  been  urging.) 
Inferential  plans  Mould  be  retained  for  these  complex  tasks. 

(2)  Provide  deductive  protocols  analogous  to  those  used  by  NASL.  Dispense 
with  inferential  plans.  This  will  require  careful  identification  of 
situations  where  the  protocol  would  be  worth  it  (such  as:  choosing  amcnr| 
answers  to  a conjunctive  goal,  ordering  conjuncts,  choosing  splits,  ordering 
implications  to  apply);  and  a way  of  efficiently  noticing  when  there  are  no 
applicable  rules,  in  which  case  brute-force  deduction  is  to  be  used. 

The  substantive  difference  between  these  alternatives  is  that  alternative  (1) 

makes  complex  inference  a kind  of  task,  and  hence  deterministic,  saving  search 

for  the  stupid  theorem  prover;  while  alternative  (2)  makes  even  complex 

inference  subject  to  backtracking,  which  is  modified  by  the  application  of 

rules. 

VI.C  Further  Work 

Let  me  list,  in  order  of  increasing  difficulty,  projects  that  are  worth 
doing  to  extend  this  research.  Some  of  them  I may  do  myself. 

(1)  Encode  more  electronics  knowledge.  The  gaps  in  ZORCH  are  described  at 
the  end  of  Chapter  III. 

(2)  Speed  the  system  up.  The  system  can  undoubtably  be  made  much  taster 
by  abandoning  some  of  my  more  elegant  programming  techniques. 

(3)  Implement  the  error -hand I ing  machinery  I described  in  Chapters  II  and 
III.  This  will  require  careful  reconsideration  of  data  dependencies. 

(4)  Unleash  the  logical  calculus.  There  are  restrictions  on  NASI ' s 
generality  which  I believe  are  due  mainly  to  inadequate  implementation  nf  the 
logical  calculus.  There  are  many  domains  which  are  beyond  its  grasp  because 
it  lacks  a notation  for  things  like  time,  belief,  and  the  actions  and  lieliefs 
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of  other  people.  To  some  degree  these  areas  could  be  handled  by  th»*  of 
modal  reference  points  for  time  intervals  and  other  people's  mmfis.  Tiu. 
system  could  simulate  other  persons'  thought  processes  uith  its  nun  tlifm  om 
prover,  and  avoid  some  of  the  problems  associated  uith  epistemic  logir. 
(HintiKKa,  19G2)  Broadening  the  syntax  of  "/rTASK"  to  include  an  agent  slot 
Mould  be  a step  toward  representing  other  persons’  purposes:  the  interpreter 

could  use  itself  to  simulate  them  as  a uay  of  understanding  their  actions. 

(Cf.  McDermott,  197Aa)  Houever,  there  is  an  "abductive"  component  to  su' h 
reasoning  (Pople,  1973,  Schank,  1975,  Lehnert,  1975)  that  is  beyond  the 
capability  of  NASL  uithout  more  substantive  revision, 

(5)  Endou  the  system  with  more  "patience  and  skepticism."  The  greatest 
weakness  of  NASL  as  it  now  stands  is  its  credulity.  It  accepts  wrong  lules 
(even  syntactically  wrong  ones)  as  readily  as  right  ones.  This  is 
unsatisfactory  for  a system  which  already  understands  its  domain  thorniighly; 
surely  one  task  it  should  be  able  to  carry  out  is  to  estimate  the  plausil>i  lity 
of  a new  rule  in  the  presence  of  its  old  ones. 

In  some  simple  cases,  a new  formula  may  be  disproved.  In  that  case,  the 
eyttem  would  be  in  an  excellent  position  to  claim  that  something  was  wrong. 
Unfortunately,  this  is  not  likely  to  happen  very  often.  The  less  important 
reason  for  this  is  that  STP  is  not  built  to  do  interesting  proofs.  The  more 
important  reason  is  that  many  theorems  have  conclusions  defined  only 
pragmat  i ca I I y , by  their  meaning  to  the  NASL  interpreter.  These  are  the 
formulas  of  the  form  "A1  and  A2  and  ...  and  Ak  Imply  C,"  where  C is  in  terms 
of  concepts  having  to  do  uith  choosing  (e.g.,  "/tRULE-IN")  or  acting  le.g.. 


"/:TASk").  These  concepts  are  in  a sense  primitive;  we  want  to  define  "good" 
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things,  that  the  method  uas  an  effective,  feasible,  and  permitted  uag  of 
carrying  out  the  task.  But,  since  there  is  no  independent  theory  of  tii»'''-p 
concepts,  a /:T0-D0  implication  cannot,  except  in  the  most  trivial  co‘‘ns,  he 
disproved  by  showing  its  method  would  not  be  permitted  (or  feasible  nr 
effective)  under  the  circumstances.  Still  another  problem  is  that  a tiipiral 
conditional  of  this  sort  is  counter  factual ; one  of  the  antecedents  is  pmhahly 
false  at  the  time  the  rule  is  heard,  making  a proof  trivial.  To  disprove  this 
rule,  the  system  would  have  to  prove  a modal  theorem  to  the  effect  that  "there 
exists  ."j  ‘possible  world’  in  which  the  antecedents  are  true  and  the  cpnseuuent 
false.  ■’ 

The  solution  to  these  problems  is  to  integrate  the  theory  of  action 
failure  with  the  theory  of  assimilation  of  new  information.  In  the  early 
stages,  this  will  be  probably  require  the  co-operation  of  a human  frienrl. 
(Shortliffe,  197G)  The  idea  is  to  place  a new  formula  or  set  of  formulas  on 
"probat ion. " (McDermott,  1974a)  Uhen  a contradiction,  action  failure,  or 
inability  to  choose  occurs,  the  system  will  check  the  formulas  involved  to  see 
which  are  on  probation  and  might  contain  errors.  The  idea  is  to  see  hou 
things  would  work  out  differently  if  the  formula  were  not  there.  If.  for 
example,  a choice  fails  because  all  alternatives  are  eliminated,  and  there  is 
a formula  on  probation  involved  whose  absence  would  have  left  some 
alternatives  in,  the  system  is  justified  in  asking  for  clarification  of  the 
new  rule. 

Notice  that  this  requires  an  "advice-taking  protocol"  for  each  class  of 
rules,  that  is,  for  each  pragmatic  predicate  the  system  knows.  It  would  lie 
attractive  if  these  were  plan  networks;  and  if  the  advice-taking  actions  in 
certain  circumstances  could  be  framed  as  policies. 

(6)  Add  a natural  - 1 anguage  interface.  This  is  difficult  in  itself,  and. 
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in  addition,  its  impact  on  the  assimilation  machinery  I outlined  is  unrioDi. 
Users  will  make  feuer  mistakes  of  notation  if  they  use  their  oun  I anfju.irjo , hut 
the  language  interface  will  inevitably  pass  ambiguities  through  for  the 
assimilation  machinery  to  worry  about. 

(7)  Add  a theory  of  learning  so  that  the  system  will  not  forget  its  more 
brilliant  insights. 
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Appendix  J --  NASL  Syntax  and  Informal  Semantics 

A formula  is  an  S-expression  enclosed  in  (brackets].  Redunrlant 
parentheses  may  be  dropped.  Thus  (US  RESISTOR  Rtf2l))  is  written  (IS  RESISTOR 
RtfZll . 

The  leftmost  element  of  a formula  or  subpattern  is  its  function.  Functions 
with  range  Itrue,  false!  are  predicates.  The  Boolean  functions  AND,  OR. 
IfIPLIES,  and  NOT  operate  on  truth  values. 

Besides  functions  and  their  arguments,  there  are  "variable  binders"  ulxirie 
job  is  to  indicate  the  names  and  uses  of  variables  in  formulas.  Those  are  the 
universal  quantifier  FORALL,  the  existential  quantifier  EXISTS,  anrl  LAflBOA, 
which  defines  functions  and  is  used  for  all  other  variable-binding  chores. 
(Lambda  may  be  typed  as  "\"  ("backslash")  to  my  LISP  system.  I will  use  this 
symbol  instead  of  "X"  throughout  the  appendices.)  Thus  thp  fol  lowing  are  NA5L 
expressions: 

(FORALL  (X)  (EXISTS  (Y)  (LOVES  ?X  ?YI)J 

(FORALL  (X)  (SATISFIES  ?X 

(\  (V)  (EXISTS  (Z)  (P  ?X  ?Y  ?Z)  )))) 

Variables  are  flagged  with  a "?"  where  used,  but  not  where  bound. 

Many  variables  are  not  bound  at  all.  As  in  most  predicate  calriilus- 
oriented  systems,  all  formulas  are  Skolemized  (Nilsson,  1971)  before  iiein,|  put 
in  the  data  base,  so  that  there  are  no  quantifiers  at  the  "top  level"  nf  an 
expression.  (Expressions  remain  quantified  inside  lambda  expressions  and  as 
arguments  to  function.)  Free  (universally  quantified)  variables  remain 
prefixed  with  a question  mark.  A "skolem  form"  represents  an  existentially 
quantified  variable.  Skolem  forms  look  like 

(SX  |var|  I id  number)  -dominating  universals-l . 

For  example,  (FORALL  (X)  (EXISTS  (Y)  (LOVES  ?X  ?Y)))  is  internally  repmoonted 
as  (LOVES  ?X  ISK  Y 79  ?X));  while  (EXISTS  (Y)  (FORALL  (X)  (LOVES  7Y)))  is 
represented  as  (LOVES  ?X  (SX  Y 71)1.  The  program  generally  abbreviates  (lie 
general  skolem  form  to  "|var|!|id  number)"  on  output;  e.g.,  (SX  Y 70  ?XI  is 
pr i nted  Y ! 70.  I occasionally  use  this  loose  notation.  (To  avoid  collisinn,  a 
hash  number  derived  from  the  skolem-form  arguments  is  usually  printed 
following  the  variable.) 

Because  quantifiers  are  retained  inside  lambda  expressions,  the  example  of 
a lambda  expression  above  is  skolemized  to 

(SATISFIES  ?X  (\  (Y)  (EXISTS  (Z)  (P  ?X  ?Y  ?Z)  ))) 

An  important  concept  in  predicate-calculus  systems  is  matching,  or 
unification,  of  two  formulas.  (Robinson,  19G5)  Two  formulas  are  said  tn  match 
• If  there  is  a substitution  for  their  variables  which  makes  them  equal.  (he 
variables  are  to  be  imagined  subscripted  with  the  name  of  the  formulas  they 
came  from,  to  avoid  confusion.  Thus  (P  ?X  (F  ?V)J  matches  IP  (F  ?X)  ?X)  uitli 
the  substitution 

Xj  (F  (F  ?Vj)l 

X2  - IF  ?Vj) 


Appendix  1 


195 


Intorndlly,  euliq  t i t u 1 1 ons  ond  aubscripta  are  handled  uaing  a method  dot  i vr.fi 
from  (Boyer  and  Moore,  1372).  (See  Appendix  A.) 

There  are  tuo  special  cases  of  matching.  Fj  subsumes  F^^  ')  ^2  ' '^d"  il 
to  the  result  of  performing  a substitution  on  Fj  and  ^2  varinnts  if 

they  subsume  each  other;  alternatively,  if  renaming  the  variables  of  Fj  tit.ikes 
it  equal  to  ^2* 

These  concepts  are  essential  to  the  operation  of  the  deductive  systom. 
(Append i x A . ) 

The  matcher  is  not  intended  to  be  a complete  unification  algorithm  for 
nth-orrier  logic,  typed  ^-calculus  logic,  etc,  A lambda  expression  nil  I m.-itrh 
another  lambda  expression  if  their  variables  differ  only  in  name.  Of  rout  se, 
free  variables  may  not  become  bound  to  fragments  of  lambda  expressions 
containing  hound  variables.  Thus  (P  (\  (X  Y)  (F  ?X  (G  ?Y)))1  nil  I not  match 
(P  (\  (U  V)  (F  ?U  'i’U))].  The  matcher  ui  I I not  create  lambda-expressions 
without  prodding.  (See  below.)  Thus,  (?F  A1  doesn't  match  (G  (H  A A))  witli  F 
-•  [\  (X)  (G  (H  ?X  ?X))1  or  any  of  the  alternatives. 

The  language  allows  formulas  to  refer  to  other  formulas.  Thus  [AfVjf  01 
(BROUN  C0U<f221 1 expresses  a property  of  (BROUN  C0Uff221 . This  is  one  of  two 
ways  in  which  NASL  expressions  may  refer  to  other  expressions.  (It  m.au  he 
considered  equivalent  to,  but  more  convenient  than,  the  use  of  Goedel  r'umiiers 
of  formulas.)  It  has  the  following  variants.  First,  every  user -cle  f i nerl 
formula  has  an  atomic  name.  (See  the  description  of  DEFMLA  in  Appendix  2.  I If 
FMLAtfSS  is  the  name  of  (BROUN  C0U</221 . we  may  write  (ABSENT  FMLA«331  . Rerond. 
an  embedded  formula  may  have  variable  parts,  called  escape  Forms,  whirh  .am 
prefixed  by  this  indicates  that  the  value  of  the  prefixed  expression 

(which  should  he  a formula)  Is  to  be  used  to  construct  the  formula.  Fnt 
example,  if  FUN  is  a function  that  maps  a formula  into  its  first  subfoimula, 
(FOO  (BAR  _(FIJN  (FA))))  - (FOB  (BAR  Fll,  Escape  forms  are  most  useful  in 
conjunction  with  variables.  Thus  (FOO  (BAR  _?FnLAl)  says,  "For  all  formulas 
7FMLA,  the  formula  obtained  by  making  the  pattern  of  7FMLA  the  arriument  of  BAR 
has  property  FOO."  (Each  such  embedded  formula  is  equivalent  to  some  open 
term,  such  that  substituting  Goedel  numbers  for  its  free  variables  gives  .a 
closed  term  whose  value  is  a Goedel  number.) 

Matching  embedded  formulas  against  formulas  with  escaped  variables  is  a 
way  of  decomposing  formulas.  This  is  used  by  some  of  the  "meta-sus terns"  of 
NASL.  For  example,  the  result  of  matching  IP  (FOO  _7X11  against  (P  (FDII  BAR)} 
is  the  substitution  X -•  ((FOO  BAR]], 

For  ease  of  manipulation  of  formulas,  the  primitive  function  OFN  Is 
understood  by  STP  to  map  formulas  onto  what  they  denote.  Thus  (OF  N (+  5 51)  - 
(+  5 51  . One  convention  I use  is  that  variables  ranging  over  formulas  start 
with  the  character  thus  7+X  might  designate  ( (FOOl  1 and  ?X  desiqn.ate 

(FOOl  . This  is  purely  a convention  and  not  part  of  the  language. 

Notice  that  all  NASL  formulas  in  this  paper  are  surrounded  by  Iht  k ^ o t '•,)  . 
For  example,  in  the  result  of  matching  (P  ?X)  against  IP  (FOO  BAR)1.  I m I to. 
"7X  has  value  (FOO  BARI,"  even  though  ?X  was  originally  matched  against  a 
subpattern  without  brackets.  This  enables  you  to  tell  unamb i guous I g iihlrh 
formulas  are  being  used  and  which  quoted.  (Actually,  when  it  comes  tn  atomic 
symbols,  I rarely  make  the  distinction  between  a symbol  and  a formula.  I 
allow  myself  to  drop  the  brackets  in  a formula  like  (FOOl.) 

The  "sense"  construct  using  single  quote  is  the  second  way  in  whirli  NA51 
expressions  may  refer  to  other  NASL  expressions.  It  allows  one  to  relfi  (o 
the  "meaning"  of  an  expression  and  no)  its  value.  For  example,  even  if  thn 
value  of  [-  NIXON  PRESIDENT)  is  false,  (POSSIBLY  'I-  NIXON  PRESIDENT)  1 may  he 
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true. 

Substitution  of  equals  is,  of  course,  prohibited  inside  any  en'lioflrlcil 
formula  or  sense. 

The  operator  POSSIBLY  is  an  example  of  a modal  predicate.  (Mi,n|hn<^  anrl 
Cresswell,  1972,  Bressan,  1972)  The  basic  system-supported  modal  npoi  alf'i  is 
[T  |reference-point I |pattern|l,  meaning  the  value  of  pattern  in  "pnsn I ii  I r> 
world"  reference-point,  (Prior,  19G7)  The  second  argument  is  implicitly 
quoted.  Thus  (T  (1970)  PRESIDENT)  would  have  value  NIXON;  and  IT  (19701  (- 
NIXON  PRESIOENTIl  would  have  value  true. 

NASL  contains  tuples  like  those  of  QAA  (Rulifson  et.  a?.,  197”').  Timy  are 
represented  using  <angle  brackets>.  Within  a tuple,  the  prefix  mo.in'j 

that  the  value  of  what  follows  is  to  be  considered  spliced  in  inslearl  nf 
substituted  directly.  Such  an  expression  is  called  a segment  form.  F rn 
example,  if  IFOO  BAR)  - (<A  B C>) . (<P  (FOO  BAR)  Q i«(F00  BAR)  R^)  - l-f  A n 
C>  Q A B C R>).  A similar  notation,  is  used  inside  embedflef)  fntnmlas. 

If  (UHIZ  BANG)  - (<[A)  IB)  IC)>),  HP  i«_(UHIZ  BANG)  0)1  - (IP  A 0 C 0) ) . 

Segment  forms  make  matching  more  complicated.  Strictly  speaking,  flireo 
two  formulas 

(P  <}tt?X  !<f?Y>)  and  IP  <A  B>1 
should  match  three  ways 

IX  - I<>) . Y I<A  B>ll . 

(X  (<A>) . Y 1<B>1)  . 

and  IX  -•  (<A  B>) , Y -*  (oil. 

My  matcher  is  too  lazy.  Occasionally  this  means  deductive  formulas  havo  to  be 
framed  in  terms  of  list  operations  instead  of  in  the  most  concise  style. 


Semant ics 

While  I am  in  sympathy  with  Hayes’s  I197A)  contention  that  the  semanMrs 
of  a representation  is  very  important,  the  subject  seems  much  too  compi icaterl 
for  practical  representat I on  schemes.  NASL  is  a modal  calculus,  which  shoulfl 
have  an  attractive  model  theory  like  Bressan’s  11972).  However,  operator  s 
like  "/;C0N5ISTENTLY"  ruin  it.  Furthermore,  there  is  a pragmatic  component  to 
many  predicates  which  could  not  be  expressed  model  theoretically.  For 
example,  "/:C0NSEQ"  and  "/:ANTEC"  both  mean  "OR,"  but  they  are  used  in 
different  ways.  Consequently,  the  most  precise  description  of  the  meaning  of 
the  language  is  a description  of  STP  (Appendix  A)  to  account  for  the  str  ictly 
semantic  "meaning"  of  a symbol;  and  the  following  index  of  pragmatic 
predicates  with  an  informal  description  of  the  pragmatic  meaning  the  system 
assigns  to  each  one. 

Here  is  a list  of  built-in,  pragmatic  predicates,  with  an  informal 
description  of  each. 
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Predicates  and  Functions  with  Meanings  to  the  Interpreter 

Task  Specification  and  Relation 

l/:TASK  |name|  < -input  pvars-  > 

(\  ( -vans-  ) laction|) 

< -output  pvars-  >] 

means  task  name,  which  consists  of  doing  action  with  the  values  nf  thn 
input  pvars  substituteil  for  the  lambda-variables,  is  worth  doing.  It  mil 
produce  output  values  to  be  bound  to  the  output  pvars. 

I/:SUBTASK  | task  name  1|  | task  name  2|) 
f/; SUCCESSOR  | task  name  1|  | task  name  2|) 

^hese  relate  tasks.  A task  will  not  be  started  until  all  Its  super  la'.ks 
enablement-status  SUBS-ENABLED  and  Its  predecessors  have  enab  I enif>n  t - 
status  SUCCS-ENABLED.  These  assertions  may  therefore  be  used  to  direrl  tti»> 
flow  of  contro I . 

[/:  TASf^-STATUS  (task  name|I 
t/:ENAB-STATUS  | task  name 1 1 
[/:  T ASK-ACT  I ON  |task  name|  |action|l 
(/: REDUCED  | task  name|J 
t/:ELABORATED  | task  name|) 

These  define  the  control  state  of  a task  as  discussed  in  Sect,  II.B.I. 
I/:P0L1CY  I task  name|  |action|l 

(/:SCOPE  Isecondary  task  name|  Iprimary  task  name|J 

These  functions  are  define  policies.  Uhen  a policy  task  has  begun.  It  is 
declared  to  be  a /:P0LICY,  usually  with  some  /:SC0PE.  It  will  be  eypliritig 
finished  with  a /lEINISH  task.  (See  below.) 

Pr i m i t i ves 


C/; flOO-MANI P (task  name|  |action|  |deletelist|  |addlist|) 

(/;nONITOR  Iformulal  (\  (|v|)  |action|  )) 
l/;SET  ■ I express i on  I |value|l 

These  are  the  non-macro  worldly  primitives.  /:H00-f1ANIP  defines  ttie 
deletelist  and  addlist  of  the  given  action.  /:f10NlT0R  creates  a polity  of 
looking  for  the  erasure  of  formula  and  creating  a task  with  the  given  .v  linn. 
(The  variable  v wi  I I be  bound  to  the  task  that  did  the  erasing.  I 7;SCI  is  usetl 
to  change  or  set  the  value  of  the  expression;  this  should  be  a mofle  I runnlitij 
(ike  voltage  or  resistance,  not  a pvar.  Its  effects  are  supported  as  timugh 
they  were  model  manipulations. 

(/: INFER  ' 1 propos i t i on  I < -task  names-  >1 

(/tFINO  (\  (|vj|  ...  |v^()  |exp|M  — > <|pvj(  ...  |pv^|> 

t/:FIND-ALL  |property|)  -•>  <|pvar|> 

(/:EVAL  ' leKpressionj]  •«>  <|value|> 

These  are  the  inferential  primitives.  Their  "effects"  are  suppmlnrl  in; 
purely  deductive  dependencies.  /:F|ND,  /:FIN0-ALL  and  /:EVAL  call  ttm 
inferential  mechanisms  of  Fig.  1.3;  /;INFER  augments  them  with  ex  tr  aor  rl  i ivn  u 
deductions.  /;FIND's  argument  is  a \-expression  of  n arguments;  STP  is  rallerl 
with  its  body  as  a request,  and  the  values  of  the  n variables  in  its  .ansimr 
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are  assigned  to  the  pvars.  If  a choice  of  answers  is  required,  this  nil  I im 
reflected  in  the  data-dependency  supporting  these  values.  /.'FIND  Al.L  l.il'ns  .a 
property  of  one  argument,  and  returns  a tuple  of  all  the  objects  uhicfi  satisfy 
it.  /:EVAL  calls  the  evaluator  and  returns  the  value. 

/:INFER  is  used  to  write  special  inference  rules.  The  propositinn  r|iven 
is  recorded,  supported  by  the  propositions  recorded  by  the  specified  task 
names.  For  example,  the  following  task  net  does  the  obvious 

(/:TASK  MINOR  <>  (\  I)  t/:FIND  (\  0 (MAN  SOCRATESII ))  <>) 

I/: TASK  MAJOR  <> 

(\  0 (/:F1ND  (\  0 (IMPLIES  (MAN  ?X)  (MORTAL  ?K)))n  <>) 

[/-.TASK  CONCLUSION  <> 

(\  (I  (/:INFER  ’ (MORTAL  SOCRATES)  <MIN0R  MAJ0R>))  <>) 


I/iOUTPUT  < -vals-  >)  -=>  < -pvars-  > 

[/:PRIM  I type)) 

/rPRIM  defines  a primitive  action;  type  should  he  one  of  *FINISHrO.  *'iFIIIP, 
or  »BEGUN.  *FINISFIEO  means  the  action  is  done:  *SETUP  means  the  action  in  a 
policy  whose  successors  may  now  be  enabled:  *BEGUN  means  the  action  is  a 
policy  whose  successors  may  not  be  enabled  until  the  policy  is  /.•FINISlK.n. 
/:0UTPUT  is  like  (/:PR|M  *FINISHE01  , but  in  addition  the  values  are  retuinorl 
to  be  made  pvar  values.  Thus,  the  task  ((F(DO)I  in 

[/:TASk  (FOO)  <’(PVl)>  (\  (V)  (/;0UTPUT  <?V>)  ) <MPV2)>) 

sets  ((PV2))  to  the  value  of  [(PVl))  when  it  becomes  available. 

t/:CONTINUE  Itask  name|  laction|) 

(/:F|NISH  Itask  name|  |action|) 

These  functions  are  userl  to  control  policies.  Uhen  all  the  primary 
subtasks  of  a policy's  scope  have  been  finished,  a /rFINISH  task  mil  be 
created  as  a subtask  of  the  policy;  it  is  up  to  the  user  to  supply  rules  to 
reduce  it.  The  user  may  also  execute  actions  of  the  form  (/:C0NTINUE  Ipnlicy- 
task)  |action|)  to  perform  intermittent  execution  of  the  policy.  (See  Sort. 

II.B.l.) 


Macro  Primitives 


(/: DO-SUBNET  |plan  schema | Ivars  map)) 

(/:PLAN-INSTANCE  [plan  instancel  |plan  schema!  |supertask|] 
l/:MAIN  |sul)task|  |supertask|] 

As  explained  in  Chapter  II,  these  formulas  are  used  in  attaching 
standardized  subnetworks  to  the  current  plan, 

(/:SEQ  laction  1 | (\  ( -vars-  ) (action  2|  )) 

I/: FORK  (action  1(  (\  ( -vars-  I < -actions-  > )1 

(/iUMILE  (primary  actioni  < -secondary  actions-  >J 
(/:DO-ALL  < -actions-  > |action|J 

These  macros  elatiorate  into  various  standard  structures.  /!SE(T  tin  ns  into 
a net  of  two  tasks,  the  first  of  which  feeds  pvars  to  the  seconri;  the  nulpuls 
of  the  second  are  the  outputs  of  the  /:5EQ.  /:F0Rk  produces  no  pvar  valm’s; 
it  sets  up  one  task  per  action,  action  1 being  the  predecessor  of  each  nf  the 
other  tasks.  The  values  of  action  I's  outputs  are  fed  to  the  surre<;<-,nr  (a-ks. 
/;UHILE  starts  all  the  secondary  actions  as  policy  tasks  with  /:SCnf'i;  er|ual  tn 
the  task  for  the  primary  action.  /;D0-ALL  carries  out  all  the  actions  in  nn 
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particular  order,  outputting  the  values  of  action’s  pvars. 

T ask  Reduc  t i on 

[/:T0-D0  1 task  name|  |action  1|  |output  pvars|  |action  2|1 

means,  "action  2 is  an  effective,  permitted,  anrl  feasible  nay  nf  dolnu  the 
task  named  uhich  consists  of  action  1 and  outputs  the  given  pvars."  Il<dii<  iny 
formulas  of  this  kind  is  the  first  resort  in  reducing  problematic  ta<'t'-.. 

[/:REPHRA5E  | task  name|  [action  formula!  [output  pvars|) 

This  action,  uhich  must  lie  reduced  by  user-supplied  rules,  is  sot  up  ulien 
/:TO-DO  deduction  fails.  See  Sect.  II. C. 2.  Its  object  is  to  leave  ttie  t.i'-.k 
/: REDUCED. 


Predicates  with  Meanings  to  the  Choice  Protocol 

I/:  CHOICE  [choice  name[  [context | (formula!) 

means  a task  or  the  executive  (context)  requires  a choice  regarrlinq  .tn'-.unrn 
to  formula.  The  choices  are  recorded  by  formulas  like 

I/tOPTION  [choice  name [ [option  namej  |ansuer|] 

I/;RULE-OUT  [option|J 

( / ; RUL  E - 1 N [ o|i  1 1 on  [ 1 

[/:RULE-TOr>ETHER  < -o(itions-  > [neu  formula)) 

These  throe  kintJs  of  formulas  are  looked  for  repeatedly,  in  this  order  on 
each  pass.  So.  for  ex.imple.  if  a formula  is  /:RULED-0UT  before  tire  /:RIII(.-IN 
rules  are  looked  at,  it  has  lost  its  chance.  See  Sect.  II.C.l. 

(/ : GU 1 ESCENCE  [choice  name)) 

is  recorded  when  no  activity  occurred  on  a choice  cycle.  It  is  us»’ri  In 
cause  further  foruard  derluctlon  of  /tRULE  statements. 


Functions  and  Predicates  Defined  by  Built-in  Axioms 

(ELT  [x|  [tuple))  means  x is  an  element  of  the  tuple. 

ISET-OF-ALL  [prop))  denotes  the  set  of  all  objects  with  the  propei  ty 
prop. 

(flAPCAR  |f[  [tuple))  denotes  the  tuple  obtained  by  applying  f to 
every  element  of  the  tuple. 

(DEL  |x|  I tuple))  denotes  the  tuple  obtained  by  deleting  the  first 
occurrence  of  x from  tuple. 

(SUBTUP  I tup  1|  I tup  2|)  means  every  element  of  tuple  I i s an 
element  of  tuple  2. 

(CONTAINS  [formula  I[  [formula  2[)  is  true  if  formula  2 occurs 
someuhere  inside  formula  1 (as  a proiier 
suliexpress  i on)  . 

(F-IS-ATOfI  [ formula) 1 true  of  atomic-symbol  formula  like  ((A)) 

(F-IS-VAR  [formula))  true  of  formula  of  variable,  like  ( (?k) ) 

(DEN  [formula))  strips  a layer  of  brackets  off  formula.  (See  above.  | 


(/;•  [x[  )y[)  true  if  x and  y match;  else  assumed  false. 
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I”  I X I ly|J  true  if  X and  y designate  the  same  thing.  To  test 
this,  the  system  first  tries  matching, 
then  evaluating  (uia  "-/>")  x and  y 
and  trying  the  match  tsjain. 

[PRESUMABLY  ' Iproposi t ion|  |use|l  if  true,  may  assume  the 

proposition  from  inability  to  disprove  it. 

(See  Sect.  1 1 .B.2. ) 

(XORl  (pat  I < -propositions-  >J  means  exactly  one  of  the  propos  i t i nn'j 

is  true  if  the  pattern  is.  E.g., 

[XORl  (LIVING  ?X) 

< (ANIMAL  ?X)  (VEGETABLE  ?X)>] 

[NFLIN  ln|  |f|]  denotes  a function  of  n arguments  which  makes  a list 
of  them  and  applies  f to  it.  E.g., 

[NFUN  3 (\  (L)  (-t-  iff?L)  )] 

- [\  (X  Y z)  (+  ?x  ?Y  ?zn 

[+  -args-1  (-  |x|  |y|]  [*  -args-J  [//  |x|  |y|l 

arithmetic  functions.  These  are  simplified  by  built-in  LISP  functions 
called  by  the  evaluator. 

[/<  |x|  |y|]  [/>  |x|  |y|l  [-/<  |x|  |y|J  [/>.  |x|  |y|) 

arithmetic  inequalities 


Predicates  with  Meanings  to  the  Theorem  Prover 

Pragmatic  versions  of  "OR": 

[/:CONSEQ  |p|  |g|] 

[/lANTEC  IpI  |g|) 

[/:GEN  Ipl  |q|] 

The  first  two  are  used  during  Ijackward  chaining  (a  call  to  STPI . Thn 
sef^ond  is  also  used  rlur  i ng  forward  chaining  (a  call  to  RECORD).  /:G[U  is 
really  a call  to  STP  in  the  midst  of  forward  chaining.  See  Sect.  lI.R.r. 

[/:PKT  |name|  [packet  varsj  -conjuncts-) 

Like  [AND  -conjuncts-),  but  indexed  differently,  and  more  effirientlu  if 
most  of  the  conjuncts  will  never  be  referenced. 

[ - / > ’ I I e f t I [right!  ) 

means  [•  [left[  [riyht[J,  hut  it  also  means  that  any  expression  sul>si mn'f|  iiy 
left  should  be  replacef)  by  right  wherever  it  appears  (except  insirle  a quriind 
expression).  in  practice,  this  replacement  is  done  mainly  in  newly  flotarhod 
deductive  conclusions, 

1/ : CONS  I STENTLY  ' [ propos i t i on[  1 

is  true  iff  the  proposition  cannot  be  refuted  by  STP  in  the  current  fl.ata 
base.  [f  the  proposition  has  free  variables,  they  will  be  converted  to  •''kolnm 
forms  before  trying  the  refutation. 


Apponil  I w 1 


m 


l/:DO  |suppnrtf>r|  |p,ilhl  < -supporters-  > |supportee|] 

(/:SUPPfirt1  < -supporters-  > Isupporteejl 

are  user)  to  access  riata  tlepentleric  i es  as  though  they  were  store'l  I ri  tu.-  ii.ita 
base.  The  /:0n  formula  is  true  if  there  is  a data  dependency  lini'inri  ti.n 
supporters  to  the  supportne.  These  are  tuple-fied  versions  of  the  lahel'ti 
treelets  riescriherl  in  Sect.  II. D.  In  (jarticular,  the  element  suppf)itet  mu'.f 
appear  in  the  supporters  trpelet,  with  labels  in  path.  For  example,  ue  mn|lit 
have 

[/:n0  (/:TASK  T«607  <>  (x  ()  (PUTON  A B))  <>) 

<Dn-ACT-FtESllLT> 

<inn  ACT-nrSlIlT  <I/:TAS1C  T</RB7  <>  tx  o iputon  a BM 
^DD-APRIN  <nOVE-DEFN>>)> 

(ON  A Bl) 

/:SUPPORT  is  simplified  version  in  which  the  supporters  must  he  jusf  a list  of 
rteductive  supporters.  It  is  equivalent  to  (FORALL  (S)  (IMPLIES  (Elf  7^  , . 
suiiporters-  >)  ( / : on  ’S  <>  < -supporters-  > | suppor tee | ) M . 


IT  (reference  point)  Iterm)] 

(S  ' I propos I t i on  I ) 

These  are  the  l5uilt-in  modalities.  The  first  Is  the  value  of  term  from  tlie 
given  reference  point;  the  term  is  usually  a fact  with  value  triip.  or  fcil’.r. 

(S  ’|facf|)  means  "S  begins  to  be  true”;  it  amounts  to  a special  treatmool  of 
the  data  rfppenriency  that  supports  it. 

(FRAME  |ref  point)  < -ref  points-  >) 

IN  ) r e f point)  '(fact)) 

Computationally  efficient  ways  of  using  modalities.  When  the  sysfrm  ti  los 
a derfucfion  of  a T-formula,  it  will  try  to  smash  the  reference  point  to  a riata 
pool  using  these  formulas.  See  Sect.  II. B. 2. 


Predicates  with  Meanings  to  the  Matcher 

For  mu  I a Mean i ny 

\nn  |sym)I  Insirie  an  embedded  formula,  matches  a variable  iiitfr 
the  symbol  sym. 

Example:  ( (\  (_?+V)  (F  (/?/?  _?+Vm] 

matches  I(\  (X)  (F  ?xm  with  +V  .4  nxi). 


1 1 DN  |n|  jk|]  The  identity  function  of  n args  that  returns  ary  k. 
I’atches  (\  <Xi...X|n|> 

(K  |n|  )c|)  The  const.int  function  of  n args  with  value  c. 


Matches  (\  *X2...Xj^j)  |c| 


Apppor)  i X 1 


(CUP  Ifunj  < -funs-  >1 

The  compo'^ition  of  fun  uith  the  fung.  If  there  are 
n of  them,  each  uith  m args,  this  matches 
(\  (|fun|  -args-)!, 

uhere  the  i th  "arg"  is  of  the  form 


(I 


fUOj  I 


?X, 


'I 


m| 


Examples:  (CHP  SIN  <?F>]  matches  (SIN!  uith  F -•  (IDN  1 11. 
(CtIP  FOO  <?F1  ?FZ>) 

matches  (\  (X  Y)  (FOO  (+  ?X  ?Y)  (-  ?Y  ?XI)] 
uith  FI  (+1  and  F2  - (\  (X  Y)  (-  ?Y  ?X)1 


Appendix  A Listing  of  DESI 

This  is  the  current  (June  27,  1977)  version  of  the  design  knoulet|(|o.  | t 
is  complete  exce|)t  for  the  definition  of  LISP  funct'ons  defining  maf  i n-.u  i i rms 
ll)<.e  CONFIG.  (See  Chapter  111,) 

In  Appendices  2 and  3,  NASL  formulas  are  defined  and  adrierl  to  Hie  dita 

base  uith  the  function  DEFIILA,  uhich  is  someuhat  similar  to  MACLISP’S  (tllUN, 

i The  expression 

t 

tOEFOLA  I name  1 |formula|  | des t i na t i on | ) 

names  the  formula  and  arids  it  to  the  data  pool  that  is  the  value  of 
destination.  The  destination  is  optional;  if  it  is  absent,  the  current  pn'>l 
CURRENT-DP*  ul I I be  taken. 


(OEFflLS  STRS» -OEFN  (-/>  fl  (STRSF  MSF  ’SUPER  ’I  ’H  ’0) 
(PRO  (/iTflS*  ’TSr  ’I  ’B  ’0» 
(/iSUBTflSF  nst  ’SUPER))) 

CENf PBL-OP*) 

(OEFnifl  0EVICE-CLBSSE3 

ixoRi  (IS  device-type  ’0) 

<(BBSIC-DEV-TVPE  ’D) 

(SUPERORDINBTE  OEV-TYPE  ’0)>D 


(OEFnifl  BBSIC-DEFN  lEQIJIV  (BBSIC  DEV-TYPE  ’X) 

(NOT  (EXISTS  (Y)  (SUB-DEV-TYPE  ’Y  ’X)  ))I) 


(OEFHLB  MBIN-OEV-TYPE  (-/>  fl  OIBIN-DEV-TYPE  ’X  ’OT)  (OEV-TYPE  ’X  ’0T)I) 

(OEFniB  SUB-OEV-TYPE-1  (-/>  B (SUB-DEV-TYPE  ’OTl  ’0T2) 

(-/>  R (DEV-TYPE  ’X  ’OTl) 

(OEV-TYPE  ’X  ’0T2))I) 


I 


AppenrJ 


(DtFHLfi  BBSlC-DfVICt  ClBSr.FS 

UORl  (Bn3IC  niV-T>Pf  '01 

.tppiniTivrofv-Tvpf  'ot 
(COfiPOSITf -OfV-TrPt  ’0» 
uoim  Ptv  Typf  ’0)>l 
CtMtPBl  0P») 


(OEPULB  COnPOSI  Tf  -OtVICt  -riBSSES 

IXORl  (C0HP03ITF  nCV-TYPE  ’0) 
<<CEN(RRL-nEV-TyPE  ’O) 
<SPFClRUrEO-OEV-IyPt  ’0)>I 
CENERRl  OP.) 


(OEEfllB  CtNERRl-OEPN  (EOUIV  (CENERRL -DEV-TYPE  ’X) 

• NOT  (EXISTS  (Y)  (DERIVED  ’X  »Y)  Mil 


(OEEHLR  SPEC-OEV-TYPE-1 

t-/>  B (SPEC-DEV-IYPE  ’OTl  ’0T2) 

(-/>  fl  (DEV-TYPE  ’X  ’OTl)  (DEV-TYPE  ’X  ’DT2I)I) 

(OEPniB  SPEC-OEV-TYPl-2 

l-/>  B (DERIVED  ’Oil  ’0T2) 

(-/>  B (SPEC-OEV-TYPE  ’0T2  ’0T3> 

(SPEC-OEV-TYPE  ’OTl  ’DT3))I) 


(OEEHLB  SPEC-OEV-TYPE-3 

I-/>  B (SPEC-OEV-TYPE  ’OTl  ’0T2)  (SPEC IBU2E0-0EV-TYPE  ’OTDI 
CENERBL-DP.) 


(OETTILB  SOUL-ON-ICE 

(-/>  B (DERIVED  ’OT  ’C) 

(-/>  B (RBIN-OEV-TYPE  ’X  ’OT) 

(BNO  (HBIM-OEV-TYPE  (SOUL  ’X)  TO 

(-/>  C (/iSUBTflSX  ’T  (DEEP-FREEZE  (SOUL  ’X)>) 
l/iSUBTBSX  ’T  (DEEP-FREEZE  ’X) ))))!) 


(OEFnLB  EBSY-OESICN 

(/■TO-DO  ’TSr  (OESICM  (\  (X)  (OEV-TYPE  ’X  ’OTl  ))  <’MBnE> 
(BBEE  ’OT))) 


(DEFHLB  .OESI-1 

l/iTO-DO  ’T  (/tREPHRBSE  ’IS*  lOESICM  _’.P]  «’OEVMBnE»l 
<> 

(/lOO-SUBMn  (OtSUfffPHRflSC-PLRN  nSK  ’KVWPBE)  <>)J 


CfNERflL-OP*) 


(OtFfILR  «0ESI-2 

(-/>  R (/!PLRN-INSTRNCE  ’PI 

(OESI-REPHRR3E-PIRN  ’«P  ’TSt  ’OEVNRHE) 

’5UP1 

(-/>  R (/;■  ’.P  tv  (_’.V) 

(RND 

(/:TflS>  (EKPLOOFR  ’P))  <> 

(V  O (0  EXPLODE  nP))  <>) 

(/rSUBTRSt  lEXPlODER  ’PI)  ’SUP) 

l/sTRS)  (flCCOUNT-FOR-RLL  ’Pi)  <> 

(V  ()  (RCCOUNT-FOR-RLL-SHRROS  ’*P)  ) <>) 

(/: SCOPE  (flCCOUNT-FOR-RLL  ’PI)  (EXPLODER  ’PI)) 
(/iSUCCESSOR  (RCCOUNT-FOR-RLL  ’PI)  (EXPLODER  ’PI)) 

(/:TflS)  (CORE -FINDER  ’PI)  <> 

(\  ()  (/:FINO  (V  («0T) 

(CORE -DEV-TYPE  ’*P  ’*0T)))) 

<■ (CORE-OT  ’PI) >) 

(/iSUBTflSX  (CORE -FINDER  ’PI)  ’SUP) 

(STRSX  (flfilN-TDS) -INFERER  ’PI)  ’SUP  <’ (CORE-OT  ’PD> 
(V  (*0T)  (/: INFER 

' (RND  (STRS)  01RFER  ’TSF)  ’T5F  <> 

(\  ()  (flRFE  (DEN  ’»0T))  ) 

<’ (UINNER  ’TSX)>) 

(/:Bfl|N  (BflXER  ’TSF)  ’TSU) 

< (CORE-FINDER  ’PI)>)  ) 

<>) 


(/[SUCCESSOR  (HRIN-IRSF-INFERER  ’PI) 
(SIOE-TRSFS-FINDER  ’PD) 


(STRSX  (SIOE-TflS)S-FINOER  ’PI)  ’SUP  <> 

(V  ()  (/[INFER 

• (FORRLL  (»ST) 

(-/>  C (SIDE-TRSX  ’*P  ’»ST) 

(EXISTS  (T) 

(RMD  (STRSX  ’T  ’TSX 

<’ (WINNER  ’TSX)> 
(OEM  ’.ST) 

<>) 

(/[SUCCESSOR 
(BRXER  ’TSX) 

’T))  ))  ) 

«>)  ) 

<>) 


(STRSX  (FERIURES-FINDER  ’P|)  ’SUP  <> 


tv  () 


(/i INFtR 

(FORflLL  (♦ri) 

(-/»  C (0-FEBTURE  UP  UFT) 

(EXISTS  (T) 

(RMO  (STRSX  >T  »TSr  <> 

(\  t) 

(D-ROTE  (OEM  T+FTII  I 
<>) 

(/■SCOPE  FT  (MRXER  ’TSX)) 
«/ 1 SUCCESSOR 

FT  (WtXER  ftSX)))  U ) 

<>)  I 

<>) 


(STRSX  (CHTHERER  FP|)  F$UP  <> 

(\  ()  (/:  INFER  M/sREOUCEO  ftsxI 
<(CORE-FINOER  fp|) 
(SIOE-Tflsrs-FINOER  FP|) 
(FERTURES-FINOCR  fp1)>)  I 

<>) 


(/■SUCCESSOR 

(/■SUCCESSOR 

(/■SUCCESSOR 

(/■SUCCESSOR 

(/■SUCCESSOR 

(/■SUCCESSOR 


(EXPLODER  FPI)  (CORE-FIMOER  ’PI)) 
(EXPLODER  FPI) 

(SIOE-TflSXS-FINOER  ’PI)) 

(EXPLODER  ’PI)  (FERTURES-FIMOER  ’PD) 
(tifllM-TRSX-INFERER  ’PI)  (CRTHERER  ’PD) 
(SIOE-TRSrS-FINOER  ’PI) 

(CRIMERER  FPD) 

(FERTURES-f IMOER  ’PI)  (CRTHERER  ’PD) 


(/■nflIN  (CRTHERER  ’PD  ’SUP)))1 
CEMERRL-OP*) 


I THE  INTENT  OF  O-EXPLOOE  IS  TO  DISCOVER  O-SHRROS,  UHICH  CENERRTE 
I (1)  CORE-OEV-TYPE,  THE  FIND  OF  DEVICE  UHICH  HRS  THE  DESIRED  PROPERTY 
, (2)  0-FERTURES.  UHICH  UIIL  GUIDE  (RS  POLICIES)  THE  HRFER  OF  THE  DEVICE 
I (3)  SIOE-TRSXS,  UHICH  TYPICALLY  ARE  CONSTRAINTS  ON  PROPERTIES  OF  THE 
I DEVICE 


(OCFniR  O-EXPLOOE 

(/: TO-DO  ’T  (O-EXPLOOE  ’.PROP)  <> 

(/■INFER  MO-SHRRO  ’«PROP  ’«PROP)  <>)1) 


(OEFHLR  O-SHRRO 

I-/>  fl  (D-SHRRO  F*P  D (_’*V)  (RNO  (#_’4CS)I) 

(FORRLL  (*C)  (/■GEN  (NOT  (EIT  ’4C  ’tCSD 

(O-SHRRO  ’4P  I\  (_’»V)  _>*CI))  II 

CENERRL-DP*) 


(OEFflLn  RCCOUNT-FOR-RLl-00 


l/i  TO-DO  ’T  (flCCOUNI-FOR-OLL-SHRROS  ’♦PI  <> 

(/iPRin  tSETUPI) 

CCNERRl-OP*) 

(OtFIH-R  nCCOUHT-TOR-RLL-nNISH 

C-/>  n (/iTBST-RCTION  ’FIN  (/iFINlSH  (KCCOUHT-FOP-OLL  ’PI))) 
(RND  l/:RCDUCED  ’FIN) 

(-/>  C (RNO  (/iPLRN-INSTRNCE  ’PI 

(DESI-REPHRRSE-PlflN  ’+P  ’♦TSF 
’♦DEVNBNE 
’♦UBY) 

’SOP) 

(O-SHBRO  ’^P  ’♦SHBRO)) 

(STBSF  (SHBRO-BCCOUNTBNT  ’♦SHBRO)  ’FIN 
< > 

(\  () 

(BCCOUNT-FOR-SHBRO  ’♦SHBRO 
’♦P)  I 

<>))))) 


(OEFflLfl  SHBRO-BCCOUNT-OO 

I/! TO-DO  ’TS)  (BCCOUNT-FOR-SHBRO  ’♦SHBRO  ’♦P)  <> 
(/:CRLL  (SHBRO-BCCOUHT-CHEBT  ’♦SHBRO  ’♦P))l 
CENERBE-DP*) 

(THIS  IS  HRNOCEO  by  B LISP  FUNCTION  (NOT  SHOUH) 

I IN  THE  CURRENT  INPlEnENTBT ION 


(OEFHLB  O-NOTE-00 

l/iTO-OO  ’TBSr  (O-NOTE  ’PROPERTY)  ♦>  (/sPRlN  »SETUP)I) 
(OEFntB  O-NOTE-FINISH 

I/iTO-00  ’TRSF  (/:FIN1SH  ’PTflSF  (O-NOTE  ’PROPERTY))  <> 
(/iPRin  *FINISHEO)|) 

(DEFULB  CO-FUNS-I  I/iBNTEC  (NOT  (OERIVEO-CQ  ’(’F  ’X))) 

(CONTROL -BTTRIBUTE  ’F)l) 

(OEFfH.«  CQ-FUNS-2  l/iRNIEC  (NOT  ( INNEOIRTE-CQ  M’F  ’X))) 

(CONTROL-BITRIBUTE  ’F)l) 


(OCFfllB  CO-SHBRO 

l/iRNTEC  (NOT  (O-SHBRO  ’♦P  |\  (.’♦V)  (.  .’♦tXPl  .’♦EXP2)))) 
(BNO  (POS-CO-SHBRO  ’♦P  ’♦V  ’♦EXPl  ’♦EXP2) 

(POS-CQ-SHBRO  ’♦P  ’♦V  ’♦EXP2  ’♦EXP))))) 


(OEFnifl  POS-CQ-SHBRO 

l/iBNTEC  (NOT  (POS-CQ-SHBRO  ’♦P  ’♦V  ’♦EXPl  ’♦EXP2)) 

(/iCFN  (NOT  (BNO  (NOT  (CONTAINS  ’♦EXP2  K|”|  .’♦V))l) 
(♦/>  MOEN  l\  (.’♦V)  .’♦tXPlI) 

»F) 
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CENERRL-OP*) 


(CONTROL -RTTRIBUTE  »FI 
(./>  MOEN  >*F)  TF))) 

(SIOE-insr  5.P 
(V  (.’*Vt 

(CONSIRRIN  <M_’*F  (|??|  _?»V)(> 

(\  (X)  (.  7t  _7*EXP2)  I)  l)>) 


(OEFHLR  CORE-DT-1 

l/iRNTEC  (HOT  (O-SHRRO  ’*P  (\  (_»*V)  (OEV-TYPE  (/»/’  _?*V» 

_>*OTIjn 


(CORE -OEV-TYPE  ’»P  >*OT)TI 


I CHOOSING  CORE-OEV-TYPES 
(DEFniR  CORE-DT-CHOOSE 

I/iRNTEC  (NOT  (CHOICE  ’C  RNSHfR  (CORE -OEV-TYPE  _»*«P  _’**0)>) 
(-/>  C (RNO  (/lOPTION  ’C  ’Rl 

(CORE -OEV-TYPE  _»»«P  _Y.»01I) 
(/tOPTION  »C  ’R2 

(CORE-OCV-TYPE  _7**02i) 

(SUB-OEV-TYPE  (OEN  (OEN  ’4*01) ) 

(OEN  (OEN  Y**02)>ll 

(/•■RULE-OUT  JRIMI) 

iPLus  oohrin-oepehoent  info  in  ZORCH 


(DEFnin  nRXE-Bflsic 

(-/>  R (BRSIC-OEV-TYPE  ’OEV-TYPE) 

(/iTO-00  nsx  (RRTE  ’OEV-TYPE)  <’NRnC> 

(/tOO-SUBHCT  (flRFE-BRSIC-NCr  ’OEV-TYPE)  <OEVNRKE>) )) ) 


(OEFHLn  HRKE-BRSIC-PLRN 

l-/>  R (/iPLRN-INSTRNCC  ’PI  (ORFE-BRSIC-NET  70EV-TYPE)  ’SUP) 
(RNO  (/iTRSK  (CRR6BCR  ’PI)  <> 

(\  () 

(/:CRLL 

(CRR6BR  (\  (X) 

(NRIN-OEV-TYPE  ’X 

’OEV-TYPE)  III  ) 

<’(OEVNRnE  ’Pl)>) 

(/tHRIN  (CRRBBER  ’PI)  ’SUPIII 

CENERRl-OPtl 
(OEFRIR  nRXE-PRin 

l-/>  R (PRIRITIVE-OEV-TYPE  ’OEV-TYPE) 

(./>  R l/iPLRN-INSTRNCE 

’PI  mRrC-BRSIC-NET  ’OEV-TYPE)  ’SOP) 

(FORRU  (0  0 C) 

(-/>  C 

(FORRLL  (XI 
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(inputs  (Otv-TYPE  >«  70EV-TYPt» 

(CONTROL  ’0  n »0  TO)  ) 
(EXISTS  (SUB) 

(STOST  ’SUB  ’SUP  <’(0EVNRnE  ’PI)> 

(N  (X)  (SELECT-VALUE 

’(’0  ’XM  ) 

<>)  ))  )))) 


(Ocfulb  nnxE-conposiTE 

l-/>  B (COnPOSITE-ntV-TYPt  ’Otv-TYPE) 

(-/>  0 (/:PLBN-|NSTBNCt 

’PI  (nfilE-BBSIC-HET  ’OEV-TYPE)  ’SUP) 
(EXISTS  (SUB) 

(STBS);  ’SUB  ’SUP  <MOtVNBBE  ’Pl)> 

(\  (X)  (EXPAND  ’X)  ) 

<>)  )))) 


(OEFTTLB  nflXt-lOERL 

t-/>  fl  (IOERL-OEV-TYPE  ’OEV-TYPE) 

(-/>  R (/:PLRN-INSTBNCt 

’PI  inB)E-BBSIC-NET  ’OEV-TYPE)  ’SOP) 
(EXISTS  (SUB) 

(STRST  ’SUB  ’SUP  <’(OEVMflnE  ’PD> 

(\  (X)  (inPLEKENT  ’X)  ) 

<>)  III) 


I 


I 

1 


(OEEnLfl  COnPONENTS-NOTICE 

t-/>  R (COnPONENTS  ’X  ’PARTS) 

(-/>  C (ELT  ’PART  ’PARTS) 


GENERAL -OP*) 


(-/>  A (nBIN-OEV-TYPE  ’X  ’OT) 

(EXISTS  (PI) 

(RNO  (/tPLRN-INSTANCE  ’PI 

(nRXE-BBSIC-NET  ’OT) 
(0EEP-EREE2E  ’X)) 
(/lEINISHEO  (GRABBER  ’Pill) 


)))) 


lOEFINITION  or  EXPAND 

|THE  HOST  GENERAL  SPECIALIZATION  ANO  ANY  OEFRULT  SPECIALIZATIONS  OE  A 
I DEVICE  TYPE  ’G  ARE  TREATED  THE  SRHE  MERE,  BUT  (A)  THE  CHOICE  RULES 
I BELOU  WILL  TRIE  THE  OEERULT,  OR  (B)  USER-SUPPLIED  RULES  HILL 
I FAVOR  THE  GENERAL. 


(OEFHLR  nOST-CENERAL-OEFN 

l-/»  A (nOST-CENERRL-SPtC  ’C  ’OT) 

(AND  (SPtC-OEV-TYPt  ’OT  ’C) 

(-/>  C (HAIN-OEV-TYPE  ’X  ’C) 


'A 


(/i  TO-DO  TTRStt  (EXPWIO  »X)  <> 
(SPEClRLIZt  ’X  »OT»  ))in 


(DEEniR  OEFflUlT-SPEC-OEFN 

l-/>  R (OtfRULT-SPEC  ’C  ’OT) 
<-/>  C (RHIN-OEV-ryPE 
(/i TO-DO  ’TRST 
(SPECIRLIZE 


»X  TCI 

(EXPRNO  ’X)  <> 
TX  ’OT)  ))J) 


(DEFm.R  SPECIRLITE-OEFN 

l-/>  C (RRIN-OEV-TYPE  ’OtV  ’OLO-OEV-TYPE ) 

(/iROO-nRMIP  (SPECIRLirE  'OEV  TOEV-TVPEI 

<•  (RRIN-OEV-TYPE  tOEV  ’OlD-t)EV-TVPE)> 
(flRIR-OEV-TYPE  >OEV  ’OEV-TyPE)>)J ) 


|IF  ONE  DEVICE-TYPE  IS  R SPECIRLIZfO  VERSION  OF  ANOTHER,  TRY 
I TO  TRFE  THE  HORE  SPECIFIC,  OTHER  THINGS  EQURl. 


(OEFm.R  SPEC-OEV-BETTER 

t-/>  fl  (DERIVED  ’OTl  ’01?) 

(-/>  C (RNO  (•/>  ’(DEM  ’.OTI)  ’OTl) 

(./>  ’ (DEN  ’♦0T2)  ’0T2)) 

<-/>  R (/:OPTION  ’C  ’R1 

I/i TO-DO  .’♦TSX  (EXPRNO  _’*OEV)  <> 
(SPECIRLIZE  _’»OEV  _’«OTi)l) 

(-/>  R (/iQUIESCENCE  ’C) 

(-/>  C (/lOPTION  ’C  ’R2 

l/i TO-DO  _’»TSX 

(EXPAND  _’«OEV) 


GENERAL -OP*) 


<> 


(SPECIALIZE 

_’»0T  _’*0T2)1) 
(/iRULE-IN  TRIM)))) 


T 


(OEFNLR  TUO-SPEC-OEVS-UORSE-THRN-ONE 
l-/>  R (DERIVED  ’OTl  ’OTR) 

<-/»  R (DERIVED  ’0T2  ’DT8) 

(-/>  C (RNO  (NOT  (/!.  ’OTl  ’DT2)) 

(•/>  ‘ (DEN  ’tOTR)  ’DTR) 

(./>  ■ (DEN  ’.DTI)  ’OTl) 

(./>  ’(DEN  ’.0T2)  ’0T2)) 

(-/>  R (/lOPTION  ’C  ’R1 

t/iTO-00  _’.TSF  (EXPAND  _’M)EV) 

<> 

(SPECIRLIZE  _’.OEV  _’*0T1)1) 

(-/>  R (/iQUIESCENCE  ’C) 

(./>  C (AND  l/iOPTION  ’C  ’R2 

I/i TO-DO  _’.TS«  TEXPRNO  _’»OEV) 
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<> 

(SPEciftiiet  j.OEv  _noT2))> 
(/:OPTION  ’C  ’B« 

(/!T0-00  _’»rs»:  (EXPBNO  _’»OEVI 
<> 

(SPECIBLI2E  _’*OEV  _7»0T»)))) 
(RNO  (/iPUlE-OUT  ’Bl) 

(/iRULE-OUT  7B?))))))))) 

iRUXILIBRY  SUBTBStS  OP  EXPBND 
(OEfniR  EXPBNO-lOOIBHiRD 

(-/>  B (/!  TflS> -BCTION  -JTS*  (EXPAND  ’DEV)) 

(TO -BE -EXPANDED  ’DEV  ?ISriII 


(OEFflLR  EXPflNSION-OBlS-00 

l/:BNTEC  (NOT  (EXPBNSION-OBl  '’DEV  ''B)) 

(/iRNTEC  (NOT  (TO-BE  EXPANDED  ’DEV  ’TN)» 

(/iTflST  (OBL  >0£V  '*)  <>  <\  <)  >a»  olM> 


IDEFULB  CENERIC-CBS 

l-/>  A (CENERIC-CB  ’CR) 

(BNO  (CDNTROL-RTTRIBUTE  ’CB) 

(-/>  R (/iPOUCY  ’TflSX 

(CONSTRAIN  <i#’OSl  M’CR  ’DEV)  l#TQS2> 
TP)) 

(-/>  C (ELT  • (’CB  ’X) 

<i#’OSl  ’PCfl  ’DEV)  i#’0S2>) 

(-/>  R (TO-BE -EXPANDED  ’DEV  ’TSX) 

(STRSX  (CR-CRtC  ’CB  ’DEV)  ’TSX 
<> 

(\  () 

tCfllCUlBTt 

M’Cfl  ’DEV))  ) 
<>)))))] 

CENERBL-OPt) 


(OEFfUfl  RCOUIRE-OO-1 

(-/>  C (BND  (REUSBBIE  ’DEV-TYPE)  (DEV-TYPE  ’X  ’DEV-TYPE)) 
(/i  TO-DO  ’TS)  (RCOUIRE  ’OEV-TYPE)  <’NflnE> 

(/lOUTPUT  <’X>)))) 


(DEFniR  RCOUIRE -DO-2 

t/i  TO-DO  ’TSX  (ACQUIRE  ’OEV-TYPE)  «’NRnt> 
(riR*E  ’OEV-TYPE))) 


(OEFflLfl  REUSBBLE-1  IPRESUBBBLY  '(NOT  (REUSABLE  ’X>)  Cl) 


■d 


J 
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(OEFRIR  REUSE -CETERIS-PORIBUS 

l-/>  fl  (/iCHOICE  E»EC  l/iTO-00  _’.TflSi:  (REQUIRE  _nOT) 

’.URYI) 


(-/>  R (/iQUlESCERCE  ’C) 

(-/>  fl  (/.-OPTION  ’C  ’fll 

l/iTO-00  _T*TflS»:  (REQUIRE  _T*OT)  <_T*N> 
(RRKE  _>*0T)J) 

</:RULE-OUT  TRl)))l) 


I 


I IF  SinPLE  EQUATION,  TRY  SOLVING  IT 
(DEFniR  EONSTRRIN-DO-1 

l-/>  E (1.  <’UN»:> 

(/iTHFINO 
(\  (U) 

(RNO  (ELT  ’U  ’QUANTS) 

I/:E0NSISTENTIY 
’ (FORRLL  (VRL) 

(NOT  (./>  TU  ’VRD)  )))  ))) 

(/iTO-DO  ’TflSF  (EONSTRflIN  ’QUANTS  (ERP  • <?F1  ’F2>))  <> 
(/iSEQ  (EONSTRflINT-RESOLVE  ’UMF  ’Fl  »F2  ’QUANTS) 

CV  (VRU 
(PROTEET 

' (SATISFIES 

’UNF  (EHP  . <’F1  7F2>)  ’QUANTS)) 

))))) 


itLSt,  JUST  ESTABLISH  POLIEY 
(OEFALA  GONSTRRIN-OO-2 

l-/>  E (OR  (NOT  (I.  ’F  .)) 

(FORRLL  (UNF) 

(NOT  (■•  <’UN)> 

(/i THFINO 
(\  (U) 

(AND  (ELT  ’U  ’QUANTS) 
(/lEONSISTENTlY 
’(FORRLL  (VAU 

(NOT  (./>  ’U  ’VAL)) 
)))  ))))  )) 

l/iTO-OO  ’TflSF  (EONSTRAIN  ’QUANTS  (ENP  ’F  ’PD)  <> 
(/sPRin  tSETUP)))) 


iOEFINITION  of  'EONSTRAINT'  — 

(OCFfUA  CONSTRAINT- 1 

l-/»  A (EONSTRAINT  ’OS  ’P) 

(EXISTS  (T)  (/tPOLlEY  ’T  (EONSTRAIN  ’QS  ’P))  )1) 


(DEFnin  CONSTRAINT-2 

l-/>  C (EXISTS  (T) 
(CONSTRAINT 


(/.POLICY  ’T  (CONSTRAIN  ’OS  »P)) 
’OS  ’P)l) 


) 


(OCrULR  CONSTRRINT-RCSOlVt-RePH 
l/iTO-00  ■’RTSt 

(/tREPHRRSE  ’TRS» 
tCONSTRflINT-RESOlVE  _’4UNC 

(V  (_’*VRRS»  _>*EKP|t 
(\  (.5.VRRS)  _>*E«P2) 

< i#_^QURMTS>I 

«’VfllUE>) 

</!SEQ  (EQN-SOIVE  ^«UN»  (IfineOR-flPPLr  (\  (_’*VRRS) 

’♦OURNTS) 

(LflnBOR-flPPLY  (\  (_>*VRRS)  _’»EXP2) 
nOURNTSI) 


(\  («RNS) 

(/ilNEER  • (RNO  (STRSk  (SETTER  TTRSk)  ’TRST  <> 

(\  (I  (/iSET  (DEN  T»UNtl 

(DEN  T«RNSI)  ) 


<>) 


(/itlRIN  (SETTER  ’TRSK)  TTRSk) 
(/;REOUCEO  ’TRSk)) 

•>)  )))) 


(OEEntR  EON-SOL VE -00-1 

(-/>  C (RNO  (ONE -OCCURRENCE  ’♦LFT  ’*UN* ) 

(NOT  (CONTRINS  ’.RCT  ’♦UNk))) 

(/:T0-00  ’TflSk  (EON-SOL VE  »»UNkF  >*LFT  ?*RCT)  <’HNSV> 
(ISOLATE  ’*UNk  ’.LFT  ’♦RCTUl) 

(OEEHLR  EON-SOL  VE -00-2 

l-/>  C (RNO  (ONE -OCCURRENCE  ’»RCT  T»UNk) 

(NOT  (CONTAINS  '♦LFT  >4UNk))l 
(/i  TO-DO  >TRSr  (EON-SOL VE  ’♦UNkF  T^LFT  T»RCTI  <TRNSV> 
(ISOIRTE  nuNk  ’.RCT  t.LFT))]) 

(OEFnifl  EON-SOL VE  00-3 

I-/>  C (NOT  (ONE -OCCURRENCE  t.’.LFT  .’.RCTl  ’♦UNkll 

(/:TO-nO  ’TSk  (EON-SOL VE  ’.UNk  >.LFT  >4RCT)  <7RHS> 
(/iCRLL  (EON-CHERT  ’^UNk  T4LFT  ’♦RCTHkll 

I THE  TERN  'ISOIRTE'  IS  FRON  RUNOT'S  rtlNl-THEORY  OF  EOORTION  SOLVING. 

1 HIS  NOTION  OF  'COLLECTION'  IS  ALSO  APPROPRIATE,  BUT  NOT  IHPLEnENTEO. 


(OEFflLfl  ISOLRTE-00-1 

I/iCONSEQ  (/!  TO-DO  MflSk  (ISOLATE  ’4UNkF  T4LFT  T.REL  ’♦RCT) 
.’RV  ’RNSV> 

(OUTPUT  <’4REL  ’♦RCT>)) 

(NOT  (•  ’♦LFT  I^UNkFIIII 


(OEFNlfl  ISOIRTE -00-2 


l/iCONStQ  (/iTO-00  ’T«S»  (ISOlfiTt  >*UMrF  ».LFT  »4da  7*HCT) 

<’RV  ’RNSV. 

(/■•SEO  USOlfllE-ONE-STEP  »*UHI[F  7*LFT  7*REL  7*ltCTI 

(\  (4NFU-LFT  4NEU-RCT) 

(ISOLRTt  ’4UHFF  74NEU-LFT 

74REL  ’4NEU-RCT)  ))) 

(•  ’4LFF  74URFF)1) 

(OEFIILB  ISOLRTE-OHE-00-4 

C/iCONSEQ  (/iTO-00  ’TR5F 

(ISOLRTE-ONE-SIEP  ’4UMFF  (4  '#_74flOOEHOSJ 
74REL  74RCT) 

.’IV  ’RV> 

(OUTPUT  .’.TERO  I-  _’4RCT  (4  '/^’.TERHS)  1 >» ) 

(NOT  (RND  (ELT  ’4TERfl  ’4ROOEMOS) 

(CONTRINS  ’4TER»1  ’4UNFF) 

(.  ’4TERNS  (0€L  ’4TERH  ’4ROOEHDS)))))) 


(OEFtlLR  SELECT-VfilUE-00 

l-/>  C (/iCONSISTENTLY 

MFORRU  (VRL)  (NOT  (./>  ’QURNT  ’VRU)  )» 

(/! TO-DO  ’T  (SEIECT-VRIUE  ’QURNT)  <> 

(/:CRLL  (CHERT  ’QURNT  (CQ-CLOSURE  ’QURNT)))))) 
iSELECT-VRLUE  IS  HRNOLEO  BY  R LISP  FUNCTION 
I IN  THE  CURRENT  inPLEHENTHT ION 


(OEFfILR  CQ-CLO-l 

|./>  • (CO-CLOSURE  ’0) 

(/:THFINO  (\  (C)  (CO-CLOSURE -ELT  ’C  ’0)  )))) 

(OEFfILR  CQ-CLO-2 

l-/>  C (CONSTRRINT  .if’QTl  ’Q  i#’QT2>  ’P) 

(CO-CLOSURE -ELT  (CONSTRRINT  .If’QTi  ’Q  ’QT2>  ’P) 
’0)1) 


(DEFniR  CQ-CLO-3 

(-/>  C (RND  (CO-CLOSURE -ELT  (CONSTRRINT  ’OS  ’P)  ’0) 
(ELT  ’01  ’OS) 

(EO  CLOSURE -ELT  ’C  ’01)) 

(CO-CLOSURE -ELT  ’C  ’0)1) 


(OEFNLR  SELECT-POSTPONE 

C-/>  R (/sTRS)  ’Tsr  ’I  (COP  DESIGN  <’PF>)  <’OEV>) 

(-/>  R (/iTRSF  ’S  ’I  (CnP  SELECI-VRLUE  <’0F>)  <>) 
(RNO  (STRSF  (SELECT-Cn-RIL  ’TSF)  ’TSF  <> 

(V  0 (00-RLL-SELECT.VRLUES  ’TSF)  ) 
<>) 

(/rSUBTflSr  ’S  (SCLECT-EN-RLL  ’TSF) I 
(/iRCOUCED  (SELECT-EN-RIL  ’TSF)) 

(-/>  R (TOPO-CHRNCE-RCTION-FUN  ’F) 
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(-/>  R (/'••Tflsr  ’T  ’IMS 

(cnp  ’f  >rs)  ’OUTS) 

(/iSUCCtSSOR 

’T  (SElECT-Ed-flll  ’Tsn )))))) 

CENERRl  -DP«) 


(OEEdLfi  nR)E-CHRNCES-TOPOLOGY 

ITOPO-CHRNCE-RCTION-rUN  nRtEI) 

(OEEdlfl  FIX-CHANCES-IOPOIOCY 

tTOPO-CHRNCE-RCTION-FUN  FIX)) 

(OEFnifl  QVRL-PROTECT 

l-/>  C (RNO  (./>  ’Q  ’VflU 

(./>  • (DEN  ’4rfiCT)  (./>  ’Q  ’VRL))) 

(/:TO-DO  ’TflS)  (PROTECT  ’(SATISFIES  ’Q  ’C  ’QURNTS))  <> 
(/idORITOR  ’♦FACT 
(\  (T) 

(/iCONTINUE  ’TASK 
(PROTECT 

’(SATISFIES  ’Q  ’C  ’QUANTS)))  )))I) 


(DEFI1LR  PROTECT-CONTINUE 

I/iTO-00  ’TAS)  (/iCONTINUE  ’PTRSF 

(PROTECT  ’(SATISFIES  ’Q  ’C  ’QUANTS))) 

< > 

(/lOO-SUBNET 

(PROTECT-CONTINUE-NET  ’PTASX  ’Q  ’C  ’QUANTS)  <>))) 


(OEFdLR  PROTECT-CONTINUE-PLAN 

l-/>  A (/iPLAN-INSTANCE  ’PI 

(PPOTECT-CONTINUE-NET  ’PTASF  ’0  ’C  ’QUANTS) 

’SUP) 

(AND  (STRSF  (RtCHECIfR  ’PI)  ’SUP  <> 

(\  ()  (VERIFY  ’(SATISFIES  ’0  ’C  ’QUANTS))  ) <>) 
(STASr  (VAIUE-F INOER  ’PI)  ’SUP  <> 

(\  () 

(/iFIND 

(\  (»NEUHON) 

(EXISTS  (NEUVAL) 

(AND  (•/>  ’Q  ’NEUVAL) 

(./>  ’(DEN  ’*NEUnON) 

(./>  ’Q  ’NEUVAL)))  )))  ) 

<• (NEUMON  ’P|)>) 

(STASF  (REnONITOR  ’PI)  ’SUP  <’ (NEUdON  ’P|)> 

(\  (.FACT) 

(/idONITOR  ’*FACT 
(\  (T) 

(/iCONTINUE  ’PTASF 
(PROTECT 
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MSBTISFIES  >Q  >C 

’OUBMTS))»  ))  )>))) 


(OEFfllB  VERIEY-OO 

I/i TO-DO  ’TSr  (VERIFY  ’ ’P)  <> 

(/iFINO  (\  ()  ’PI  in 

(OEFULB  SPEC-SCHEHR-OEFN 

(-/>  B (SPEC-SCHEBB  ’SCHl  ’SCH2) 

(-/>  B (/!Pt.flN-INSTflNCE  ’PI  ’SCHl  ’SUPI 

(/iPlBN-INSTBNCE  ’PI  ’SCH2  ’SUPDll 

iTHIS  PREDICBTE  IS  USEFUL  IN  RELATING  B SCHEBB  TO  ITS  SPECIBLI2ERS 
(DEFBIB  REOUCE-OEFN 

(-/>  B (RFDUCE  ’TflSIS  ’TBSIl 

(BNO  (-/>  C (ELT  ’T  ’TBSFSl  (/iSUBTflSF  ’T  ’TBSFII 
(/tREDUCEO  ’TBSrilII 


I THIS  IS  B USEFUL  PREDICATE  ON  FR02EN  TBSFS 
(DEFflLB  FUNCTION-OEFN 

l-/>  B (FUNCTION  ’DEV  ’TSI  I 

(-/>  B (BBIN-DEV-TYPE  ’DEV  ’OTI 
(EXISTS  (BCQI 

(BNO  (/:TflST  ’BCD  ’I  ’B  <’OEV>l 

(/iTBSL-BCTION  ’BCD  (ACQUIRE  ’OTII 

(/iREOUCEO  ’BCQI 

(REDUCE  .’BCO>  ’TSKI)  IIII 


(IF  ONE  PLBN-SCHEBB  IS  fl  SPECIBLICED  VERSION  OF  BNOTHER,  TRY 
I TO  TBFE  THE  BORE  SPECIFIC.  (THIS  IS  REALLY  ilORE  GENERAL  THAN 
( THE  UORLO  OF  DESIGN. I 

(DEFBLH  SPEC-IS-BETTER 

(-/>  B (SPEC-SCMEBB  ’SCHl  ’SCH2I 

(-/>  C (BNO  (./>  ’ (OEN  ’♦SCHII  ’SCHII 
(./>  ’(OEN  ’.SCH2I  ’SCH2II 
(-/>  B (/lOPTION  ’C  ’B1 

l/iTO-OO  _’*TSF  _’*BCT  _’»OUTS 

(/lOO-SUBNET  _’.SCH1  _’*VBRSIIII 
(-/>  B (/lOPTION  ’C  ’B2 

l/iTO-00  _’»TSF  _’.BCT  _’.OUTS 
(/t 00-SUBNET  _’»SCH2 

_»»VBRS2M) 
(/iRULE-IN  ’Alllllll 


(OEEBLA  TUO-SPECS-HORSE-THBN-ONE 

I-/>  fl  (SPEC-SCHEBB  ’SCHl  ’SCH8I 

(-/>  fl  (SPEC-SCHEBB  ’SCH2  ’SCHBI 

(-/>  C (AND  (NOT  (/i.  ’SCHl  ’SCH2II 
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(./>  ■ (OtN  ».SCH»)  >SCH*) 
(./>  • (OtN  ’»SCHl)  ’SCHlt 
(./>  • (OtN  ’♦SCH?»  7SCH2I) 
(-/>  R 

(/iOPTION  ’C  ’fll 


I/:  TO-DO  _’*TSi:  _’«fiCT  _’»OUTS 
(/iOO-SUBNtT  _7.SCH1  .’♦VRRSJ»J» 
(-/>  C (RNO  (/:OPTION  >C  ’R2 

I/i  TO-DO  J.TST  _n«CT 
_’.OUTS 

(/lOO-SUBNtT  _T.SCH2 
.’♦VRRS2M) 
(/iOPTlOH  TC  ’08 
I/! TO-DO  J«TS»:  _’«RCT 
_’»OUTS 

(/lOO-SUBNtT  _’.SCHB 
_’»VRRSB)1  >) 
(RNO  </;l>ULe-OUT  ’fll) 

(/sBUlt-OUT  Tfl2)))))))> 


Appendix  3 --  A Listing  of  ZORCH 

This  is  the  current  version  of  DESI’s  electronics  knowledge.  Much  of  it 
interacts  with  the  more  general  rules  of  the  previous  appendix. 


(INTStCT-OISPRRITr*  IBOBI 
(Ruoc  ’(LIST  (leoesB.  iseeeB.  b.siu 

iPHYSICRL  THOUltOCt 

,EVtRY  Moot  IS  R TtPniNfll 

(OttniR  NOOt-TRniN 

irORRU  (XI  (-/>  R (DtV-IYPt  ’X  NOOtl  (OfV-TYPt  ’X  TtROINRUII) 

|XCL  TOR  DtVICtS 
(DCFnifl  rcL-1 

l-/>  R (TtRniHRl -Nonts  ’X  TTROIN-TUP) 

(CONSTRRINT  (nOPCRR  (IRriBOR  (Tl  '<1  (’T  ’XI)  ) 
’TRnIM-TUP) 

(NfUN  (ItNCTH  nRHIH-TUP) 

(LROBOR  (LI  (•  (*  >«’L)  BID II I 

iXCL  FOR  NOOtS 
(OtFHLR  FCL-2 

r-/>  R ’ (NOOt-TfPniNRlS  ’NOOtl  ’TRUIM-IUP) 

(CONSTRRINT  <’ (I  ’NOOtl 

(RinOPCRR  (\  (Tl  'U  ’Tl  I 
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>TRniM-TUP)> 

(NFUN  («  (LENGTH  ’TRniN-TUP)  1) 

(inneon  a)  (•  <•  <«n.)  i))))ii 

I . . .AND  COnPOSIIE  DEVICES 
(OEFULH  rCL-3 

t-/>  H (COnPOSITE-OEVTYPE  ’OT) 

(-/>  B (OEV-TERHINIHS  'OEV  ’IHHIM-TUP) 

(CONSTRRINI  (flRPCBR  (\  (T)  MI  ’T1  ) 

’TRHIM-TUPI 

(NEUN  (LENGTH  nNHIN-TUP) 

(LnnBOB  (U  (•  («  if’L)  «) 
)))))) 


irVL  FOR  NODES 
(OEFHLB  FVl-1 

I-/>  fl  (./>  ' (N0DE-TER(1|NBLS  ’NODE)  ’TRHIN-TUP) 

(-/>  C (ELT  nRniN  ’TRDIN-TUP) 

(COHSTRBINT  <MV  URfllN)  '(V  »NOOE)>  .)))) 

i 

I 

|SOHE  TERHINflLS  HBVE  NODES  THAT  THEY  BRE  TERHIHRLS  OF 

(OEFnLB  NOOE-OF-l  l-/>  B (./>  • (NODE -TERHINBLS  ’N)  ’TS) 

(-/>  G (ELT  n >TS)  (NOOE-OF  »T  ’N)))) 

(OEFflLB  NODE-OF-2  (PRESUnBBLY  ’(NOT  (NOOE-OF  n »N))  Cl) 


(NODES  CRN  BE  OERGED 
(OEFnLB  NOOES-nERGE-nBNIP 

l-/>  C (BNO  (•/>  ■ (NOOE-TERniNBLS  ’NU  ’Tl) 

(./>  ■ (NOOE-TERniNBLS  ’N2)  »T2)) 

(/idOO-nPNlP  ’TBST  (NODES-OERGE  ’N1  ’N2) 

.’(./>  ’ (NODE -TERHINBLS  ’Nil  ’Tl) 

*(./>  ■ (NODE-TERHINBLS  ’N2I  ’T2)> 

<•(./'>  • (NODE -TERHINBLS  ’Nl)  (UNION  ’Tl  ’12)) 
• (./>  ’’N2  ’Nl)>))) 


(TERniNBLS  CBN  BE  CONNECTED  TO  CREBTE  NEU  NODES  OR  HCRCE  OLD  ONES 

(OEFnLB  TRniNS-CONNECT-OO-1 

I-/>  C (BND  (NOOE-OF  ’Tl  ’Nl)  (NOOE-OF  »T2  ’N2)) 

T/iTO-OO  ’TBSr  (TRAINS -CONNECT  ’ll  >T2)  <> 
(NOOES-nERGC  ’Nl  ’N2))ll 

(OEFniR  TRBINS-CONNECT-00-2 

(-/>  C (BNO  (NOOE-OF  ’Tl  ’Nl) 

(CONSISTENTLY 

’(FORBLL  (N)  (NOT  (NOOE-OF  ’T2  ’N))  )l 
(•/>  ’ (NOOF-TERRINDLS  ’Nl)  ’TSD) 
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(/:nOO-rinMlP  ’TBSI.  nonlNS-CONNtCT  7T1  ?T2) 

.'(./>  ' (NOOE-TERHIHflLS  ’Nl)  ’TS1)> 

<■(./>  • (NPOE-TERUlNflLS  ’Nl)  <»T2  '#’TSl>l>)n 

IDErniR  TRt1|NS-CONNECT-DO-3 

l-/>  C (BNO  (NODE-OF  ’T2  ^N2I 
(CONSISTENTLY 

’(FORBLL  (N)  (NOT  (NODE -OF  ’T1  TN))  )) 

(./>  • (NOOE-TERflINRLS  ’N2I  »TS2)) 

{/snOO-nONlP  ’TBSF  (TROINS-CONNECT  ’T1  >T2) 

<■(./>  • (NOOE-TERniNRLS  ’N2)  ’TS2)> 

<’(./>  • (NOOE-TERniNfllS  ’N2)  <7T1  l#’TS2>)>M) 

(DEFnin  TRniNS-CONNECT-00-4 

l-/>  C (UNO  (CONSISTENTLY 

’(FORRIL  (N)  (NOT  (NODE -OF  ttI  yN))  )) 
(CONSISTENTLY 

'(FORRLL  (N)  (NOT  (NODE-OF  YT2  ’HI)  ))) 
(/inOO-nONlP  YTRSF  (TRn INS-CONNECT  YTl  YT2) 

< > 

<• (EXISTS  (H) 

(./>  ■ (NOOE-TERniNRLS  ’N)  <’T1  YT2>)  )>»)» 


I INSERT  INC  R DEVICE  INTO  R NODE  BRERrS  IT  INTO  TUO  NODES 
(OEFNER  OtV-INSERT 

t-/>  C (RNO  (•/>  • (NOOC-TERKINfiLS  ’NODE)  ’TSI 

(.  (SET  YTSII  (SET  <I#YTS1  i#7TS2>))) 
(/inoO-riRNIP  7TBST 

(OEV-INSERT  YQ  ’NODE  ’T1  ’TSl  ’T2  7TS2I 
<■(./»  ■ (NOOE-TERniNRLS  ’NOOE)  ’TSI> 

<Mt/>  ' (NOOE-TERtllNRLS  yNODEI  <’T1  i#yTS1>) 
•(EXISTS  (NEUNOOEI 

(AND  (DEV-TYPE  YNEUNOOE  NOOE) 

(./>  ’(NOOE-TERniNRLS  ’NEUNOOE) 
<7T2  '#’TS2>))  )>)I) 

(OEFIILR  PORT-DEFN  IPRiniTIVE-OEV-TYPE  PORT)) 

tPORTS  CRRRY  VOLTRCE  OR  CURRENT 

(OEFNLR  PORT-TR»ONOnY  IXORl  (OEV-TYPE  ’X  PORT) 

.(V-PORT  YX)  (I-PORT  YX)>) 

CENERRl -OPt) 


(OEFnLfl  PORT-flEOIun-I 

l-/>  C (V-PORT  ’X)  (./>  • (PORT-nEOlUn  YX(  VOLTRCE)!) 
(OEFniR  PORT-nEOIun-2 

I-/>  C (I-PORT  ’X)  (./>  ’(PORT  nEOlUn  YX)  CURRENT)!) 
iflOST  PORTS  RRE  VOLTRCE  PORTS 

(OEFHLR  PRES-V  PORT  I-/>  C (RNO  (OEV-TYPE  YX  PORT) 

(CONSISTENTLY  ’(V-PORT  »X))) 
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(V-PORI  ’X)l) 


(fl  NtST  IS  nROE  UP  Of  PORTS  RNO  IS  IlSUf  B PORT 

(OEPHLA  NEST-PORT  l-/>  R (OEV-TVPE  ’X  NEST)  (OEV-TYPE  ’X  PORT)!) 

(OEfriLR  NEST-OF-1  I-/>  fl  (./>  ’ (NEST-PORTS  ’N)  ’TS) 

(-/>  C (ELT  n ttS)  )NEST-Of  ’T  ’N))l) 

(OEFfTEB  NEST-OF-2  IPRESUnBRlY  ’(NOT  (NEST-OF  »T  >N))  Cl) 

iPORTS  ARE  HONES  FOR  SICNBLS 

|XVl  FOR  PORTS 
(OEFNLB  rVl-2 

{-/>  fl  (./>  ’(NEST-PORTS  ’NEST)  ’PORT-TUP) 

(-/>  C (ELT  ’PORT  ’PORT-TUP) 

(RNO  (-/>  R (SIGNAL -HONE  ’SIC  ’PORT) 

(SIGNAL -HONE  ’SIC  ’NEST)))))) 


(OEFNLR  SICNfll-HOflE 

l-/>  fl  (SIGNAL-HONE  ’SIG  ’PORT) 

(./>  ’(PORT-SIGNAL  ’PORT)  ’SIOl) 

I these  actions  are  ANAIOCOUS  TO  THE  NODE  ACTIONS 

(DEFNER  NESTS-NERGE  NRNIP 

l-2>  C (AND  (./>  ’(NEST-PORTS  ’Nl)  ’Tl) 

(./>  ’(NEST-PORTS  ’N2)  ’T2)) 
(/.NOO-NANIP  ’TflSF  (NESTS-NERCE  ’Nl  ’N2) 

<’ (./>  ’ (NEST-PORTS  ’Nl)  ’Tl) 

’(./>  ’(NEST-PORTS  ’N2)  ’T2)> 

.’(./>  ’(NEST-PORTS  ’Nl)  (UNION  ’Tl  ’T2)) 
’ (./>  ’’N2  ’Nl)>)l) 


(OEFNLA  PORTS-CONNECT-OO-I 

l-/>  C (ANO  (NEST-OF  ’Tl  ’Nl)  (NEST-OF  ’T2  ’N2)) 

(/■•lO-rO  ’TflS)  (PORTS -CONNECT  ’Tl  ’T2  ’TyPE)  <> 
(NESTS-NERGE  ’Nl  ’N2I))) 

(OEFHLA  PORTS -CONNECT  00-2 

l-/>  C (ANO  (NEST-OF  ’Tl  ’Nl) 

(CONSISTENTLY 

’(FO»ALL  (N)  (NOT  (NEST-OF  ’T2  ’Nl)  )) 
(./.  ’(NEST-PORTS  ’Nl)  ’TSD) 

(/iNOO-NANIP  ’TflST  (PORTS-CON^cCT  ’Tl  ’T2  ’TYPE) 
<’(./>  ’(NEST-PORTS  ’Nl)  ’TSII» 

.’(./.  ’(NEST-PORTS  ’Nil  «’T2  i«’TSI>)>))) 

(OCFNIN  PORTS-CONNECT-00-3 

|./>  C (ANO  (NEST-OF  ’T2  ’N2I 
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IC0NSI5TENII  V 

’(fORPU  IN)  INOT  (NtST-Of  ’T1  ’Nl)  I) 
l./>  ' (NfST-PORTS  ’N2)  ’TS2)) 

(/!noo-nnNiP  nn5>  iporis-CONnect  ni  jt2  ’type) 

.•t./>  ' INESI-POPT3  ’N2)  >TS2)> 

<•(•/>  MNESI-P0RI3  ’N2)  »ni  i#'>TS2>)  >)I  ) 

(DEEHLR  PORTS-CONNECT-nO  * 

I-/>  C inMO  ICON3ISTENUV 

•PnRPIL  IN)  (NOT  (HEST-OE  ’TI  ’N>)  )) 

(CONSISTENIIY 

•tFORRU  (N)  (NOT  (NEST-OE  ’12  'N)>  )l) 

(/inOO-OONIP  ’TfiSE  (PORTS-CONNECI  ’Tl  ’T2  ’TYPE) 

< > 

.’(EXISTS  (N)  (./.  '(NEST-PORTS  ’NI  «’T1  ’I2>)  )»'/) 


(OEEHLB  PORTS-CONNECT-OIRECT-00 

l-/>  C (BNO  (PORT-TEROINOlS  'PRTl  .’TOPI  ’*0T2>) 

(PORT-TEROINRl  S 'PRT2  .’TOP2  ’BOT2>) 

(OR  (/:f100  I1BNIP  ’TRSE  (TRHINS-CONNECT  ’TOPI  ’TOP2I 
’DEL  ’POO) 

(/;fioo  noNip  ’TPs»  <rFfftMs-coMnecr  ’#on  'bou/ 

’DEL  ’000))) 

(/:nOO  nONIP  ’TP3E  (PORTS-CONNECT  ’PRIl  ’PRT2  DIRECT) 
’DEL  ’ODDI  I ) 


(OEEHLR  PORTS-CONNICT-CRPRCITIVE  00 

I-/>  C (RNO  (PORT  TERMINOIS  'PRTl  .’TOPI  ’B0T1>) 
IPORT-TERdlNOLS  ’PRT2  .’T0P2  ’»0T2>)) 

</i TO-DO  ’TS)  (PORTS-CONNECT  ’PRTl  ’PRT2  CRPRCITIVt)  .> 
(CONEJC  .CRPRCITOR, 

(\  lO 

. (TRniNS  connect  (/I  ’Cl  ’TOPI) 

(TPniNS-CONNfCT  (#2  ’C)  ’T0P2)>  Dili 


i (OfFOLR  PORTS-CONNECT-INOUCTIVE-00 

l-/>  C (RNO  (PORT-IERniNOLS  ’PRTl  .’TOPI  ’B0T1>) 
(P0RT-TtR(l|N«l  S ’PRT2  .’T0P2  ’B0T2>I) 

(/i  TO-DO  ’T3E  (PORTS-CONNECT  ’PRTl  ’PRT2  INOUCTDEE)  «> 
(CONE  1C  .TRRNSEORHER. 

(V  (LI) 

. (TRUINS-CONNECT  (#7  ’lU  ’TOPI) 
MRfllNS-CONNECT  (#4  ’ll)  ’T0P2)>  HID 

I 

, iSICNRLS 

(Otrnifl  EL-SHRPt  HIT  (Ei-SHRPi  ’ini  .Hunp  sPirt.H 


lOtFIKR  FF-FREQ  I./>  MFF-EREQ  (FF  ’F  ’LID)  ’FI) 
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(DCFnLfl  Ff-i«Monm  t./>  • irF-iRNOiwRr  (ff  ’f  »lh))  ’ini) 


(OEFtlLR  PERIOOIC-FREQ-PIC 

l-/>  C (PERIODIC  ’S  ni 

(./>  ■ (FREQ-PICTURE  ’S) 

(UNION  (P0SSIBIE-0C-SU8-PIC  ’SI 
(SERIES-SUB-PIC  ’Simi 


(OEFnin  DC-FERTURE-1 

l-/>  C (AND  (PERIOOIC  ’TFUN  ’Tl 

(.  (OFFSET  ’TFUN)  ’V) 

(/>  (PBS  ’V)  ei) 

(./>  ’ (POSSIBLE-OC-SUB-PIC  ’SI 

<(FF  • (OC-LBNOnRRF  ’TFUN  ’V))>)l) 


(OEFNEB  DC-FEflTURE-2 

l-/>  C (UNO  (PERIOOIC  ’TFUN  ’T) 

(.  (OFFSET  ’TFUN)  Bl) 

(./>  ’(POSSIBLE-OC-SUB-PIC  ’SI  oil) 

(DEFInn  DC-lRNOnPRI-I 

I./>  ’(FL-SHPPE  (DC-lBNOflRRF  ’TFUN  ’VI)  SPIFEl 
CENERBL-OP*) 

(DEFBLB  OC-LRNOnBRt-2 

l./>  ’(FI -HEIGHT  (OC-lflNOnHRF  ’TFUN  ’VI)  ’VI 
CENERBL-OP* I 


(DEFBLB  FREQ-PIC-ELTS  IIBPLIES  (ELT  ’*  (FREQ-PtC  ’SI) 

(IS  FREQ-FEBTURE  ’XI) ) 


(DEFBEB  SPIFES 

I-/>  B (PERIOOIC  ’TFUN  ’T) 

(FORBLL  (X)  (-/>  C (ELT  ’X  (FREO-PICTURE  ’TFUN) I 
(•  (FL-SHBPE  ’X)  SPIXEI)  II) 


IDCFBIB  SINUSOIDBL -SPITE 

l-/>  C (BNO  (PERIOOIC  ’TFUN  »T) 

(SINUSOIOBL  ’TFUN) 

(BI1PLITUOE  ’TFUN  ’HI) 

(./>  ’ (SERIES-SUB-PIC  ’TFUN) 

<(FF  I (SIN-LBNOnBRT  ’TFUN  ’T  ’B))>lll 


(OCFBLB  EVERYOTHER-SfRIES 

l-/>  C (BNO  (PERIODIC  ’TFUN  ’Tl 

(NOT  (SINUSOIOBL  ’TFUNII 
(FORBLL  (XI 

(«  (’TFUN  ’X)  (’TFUN  (♦  ’X  (//  ?T  211)1  II 


Appenfl  i k 3 


222 


(./>  ’ (stRits-sue-Pic  nruN) 

(SERIES  (•  2 PI  (//  1 nn  («  4 PI  (//  I 7TM 
SPirE 

(V  (Nl 

(INTECRRL  e n 
(\  (U) 

(•  (’TFUH  >U) 

(COS  (*  2 PI  (-  (•  2 ’N)  1) 
7U  (//  1 JT)»)I  )) 


Ml ) 


) 


(OCrniB  STRBICHI-SERIES 

I-/>  C (UNO  (PERIOOIC  ’TFUN  ^T( 

(NOT  (SINUSOIOOL  ’TFUH)) 

(EXISTS  (X) 

(NOT  (.  (’TFUN  ’X) 

(’TFUM  (♦  ’X  (//  ’T  2)))))  )) 

(./>  • (SERIES-SUB-PIC  ’TFUN) 

(SERIES  (»  2 PI  (//  1 ’T))  (*  2 PI  (//  1 >T)I 
SPDE 
(\  (H) 

(INTECRRi.  » ’r 
(\  (U) 

(•  (’TFUN  ’U) 

(COS  (•  2 PI  ’N 

’U  (//  I ’T))))  ))  ) 

)))) 


(OEFIILB  SIH-LBNOnBRF-SHBPE 

(./>  ' (FL-SHBPE  (SIH-LBNOORRT  ’TFUN  ’T  ’fl))  SPIFEI) 


(OEFflLB  SIH-LBNOnBRX -HEIGHT 

|./>  ’(FL -HEIGHT  (SIN-IBNOHRRX  ’TFUN  ’T  ’B)l  ’Bl ) 


(OEFIILfl  SINU*  l-/>  C (BHO  (ELI  ’SIN  ’FS) 

(SINUSOIOm.  ’SIN) 

(FORBLL  (F) 

(EXISTS  (B) 

(IHPLIES  (ELT  ’F  (DEL  ’SIN  ’FS)) 
(/i.  ’F  (1C  1 ’BM)  ))) 
(SIHUSOIOBL  (CHP  « ’FS))I) 


(DEFHLB  SINU*  {-/>  C (BNO  (ELT  ’SIN  ’FS) 

(SIHUSOIOBL  ’SIN) 

(FORBLL  (F) 

(EXISTS  (B) 

(IHPLIES  (ELI  ’F  (DEL  ’SIN  ’FSI) 
(/i.  ’F  (F  1 ’B)))  ))) 

(SIHUSOIOBL  (CHP  * ’FS))I) 


(OCFnLB  SIN-SIN  t-/>  C (LINEBR  ’F) 


(SiNusoioni  icnp  sin  <7F>))D 


(DEFULn  COS-SIN  I-/>  C (UNEflU  ’F) 

ISINUSOIORL  (Cnp  cos  <’F>))I) 

(DCFncn  UNI  (linerr  (idn  >n  ’on 

(OCFIHR  IIN2  (-/>  C (RNO  (ELT  ’UN  ’FS)  (UNERR  ’UNI 
(FORfiU  (FI 
(EXISTS  (R) 

(IKPUES  (ELT  ’F  (DEL  ’UN  ’FS)' 
(/i.  ’F  (K  1 ’RIM  III 
(UNERR  (CnP  * ’FSni) 

(OEFKLR  LIN3  I-/>  C (FORRLL  (F)  (INPLIES  (ELT  ’F  ’FS)  (LINERR  ’F)) 
(LINERR  (CNP  ♦ ’FS)))> 

(OEFRLR  LIN4  (-/>  C (LINERR  (CtlP  ♦ <’F1  (\  (X)  (-  (’F2  >X))  )>)) 

(LINERR  (CnP  - <’F1  ’F2>))I) 


(OEFRLR  LINS  (-/>  C (RNO  (LINERR  ’FI I 

(/!.  ’F2  (F  1 ’R))) 
(LINERR  (CnP  //  <’F1  ’F2>I)I) 

(OEFRLR  SIN-PERIOOIC  IPERIOOIC  SIN  (*  2 PIMI 

(OEFRLR  COS-PERIOOIC  IPERIOOIC  COS  (•  2 PDI) 


(DEFRLR  PRES-MOT-SIN  IPRESURflBir  ’(NOT  (SINUSOIDRL  ’F))  Cl) 


(OEFRLR  OFFSET-DEFN  (-/>  R (PERIOOIC  ’TFUN  ’T) 

(./>  ’(OFFSET  ’TFUN) 

(//  (INTECRRL  • ’T  ’TFUN)  ’Till) 


iLINERR-OENIVEO  ROOELS 

idSOLRTE  T1  T2)  IS  R UORLO  IN  UHICH  THE  CIRCUIT  IS  DECOUPLED 

(DEFRLR  REF-ISO  IIS  REF  (ISOLRTE  ’TRRINl  7TRHIN2)I) 

(OEFRLR  FRRRE-ISO  KFRRRE  (ISO  ’TRrCNI  ’TRRIN2)  <(HERE)>)I) 

(DEFRLR  ISOLRTE -DEFN-I 

(./>  C (RNO  (•/>  ' INODE -TERRINRLS  ’NI) 

<'#’TSIl  ’TRniNl  ■«’T$12>) 

(•/>  ' (NOOE-TERRINRLS  ’N2) 

<i#’TS21  ’TRRIN2  i#’TS22>)) 

(T  (ISOLRTE  ’TRRINl  ’TRRIN2) 

(RNO  (•/>  '(NOOE-TERRINRLS  ’Nil 
<>#’TSII  I#’TS12>) 

(•/>  ’(NOOE-TERRINRLS  ’N2I 
<I#’TS21  i«’TS22>)))l) 


(OtFntn  ISOinTE-OEFN-2 

I-/>  C (•/>  ■ (NOOE-TERniNPLS  ’Ni) 

<iinsii  ■’TRniMi  i#nsi2>t 

(H  USOIRTE  nSniNl  ’TRfllNZ) 

’ (./>  • (NOOE-TERniMBLS  ’Ml) 

<i#nsn  ’TRfiiNi  i#nsi2>))i) 


(OErntR  isolrte-oeeno 

t-/>  C <■/>  • (NOOt-TERniNPLS  ’N2) 

<'/’TS21  ’TRniM2  '/’TS22>) 

(N  USOLPTE  nRtllNl  ’TRniM2) 

’(./>  ’ (NOOE-TERniNPLS  ’M2) 

<i»’TS21  ’TRniN2  'f’TS22>))l) 


|FOR  THE  FOLLOUINC  REFERENCE-POINT  DEFINITIONS, 

) SEE  CIRCUIT  PPCTETS  FOR  RLTEREO  COHPOMENT  PROPERTIES  IN  ERCH  REF 

(DEFNLR  REF-OC  IIS  REF  (OC))) 

(OEFNIR  FRRnE-OC  KFRRrtE  (DC)  < (HERE) >1)1 


(OEFniR  REF-SSS  IIS  REF  (SSS  ’FREO))) 

(OEFHLR  FRRflE-SSS  NFRRHE  (SSS  ’S)  *(HERE)>))) 

(DEFniR  REF. INC  IIS  REF  (INC)I) 

(OEFniR  FRRRE-INC  KFRRHE  (INC)  *(HER£)>)I) 


(OEFniR  REF-PRSSIVt  IIS  REF  (PRSSIVED) 

(DEFniR  FRRHE  PRSSIVE  I (FRnnE  (PRSSIVE)  <(HERE)>))) 

I INTERRCTIONS  -- 

I THIS  HERNS  (T  (DC)  (DO)  . (DC) 

(OEFniR  OC-IDCn  (REF-IOCnPOIENT  (DC)I) 

(OEFniR  ISOlRTE-IOtn  (REF- lOEnPOIENT  (ISOIRTE  ’TRniNl  ’TRniN2))) 
(OEFniR' SSS-IOEn  IREF-IOEnPOTENt  (SSS  ’S)l) 

(OEFniR  PRSSIVE-IOEn  IREF-IDEOPOIINT  (PASSIVE))) 

(OEFniR  INC-)DEn  IREF-IOEnPOTENT  (INC))) 

(OEFniR  OC-)SO  !•/>  ’ (T  (OC)  (ISOIRTE  ’TRniNl  nRnlN2M 
(T  (ISOIRTE  ’TRniNl  ’TRniN2)  (00)1) 
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(OCrtILR  PRSSIVt-OC  (•/>  MT  (PBSSIVE)  (DC)»  <T  (OC)  (PASSIVE)))) 


lINFORnRTION  RBOUT  REPHRASING  ELECTRONIC  DESIGN  PROBLENS 

lO-SHRROS  RRE  FRRGRENTS  OF  DESIGN  PROPERTIESi  THOSE  OERIINC  HITH 
I CONTROL  QURNTITIES  RRE  inPORTRNT 

, THESE  APPLY  TO  ‘lO-  OEVICES 

(OETHLR  CQ-V-GRIN  (GENFRIC-CR  V-GRINI) 

(OEFHLR  CO-P-GRIN  IGENERIC-CR  P-GRIN)) 

(OEFHLR  CQ-IZ  IGENERIC-CR  INPUT-ZI ) 

(OEFHLR  CQ-OZ  IGENERIC-CR  OUTPOT-ZI) 


(DEFHLR  V-CflIN-SHRRO 

{-/>  R (0-SHRRD  ’*P  I\  (_nv)  (•  (V-CflIN  (|?T|  _>*V>) 

_T*C)I) 

(RNO  (SIOE-TRS)  ’*P 

(V  (_’.V) 

(CONSTRAIN  <’(V-CRIN  (|»|  _T»V))> 

(\  (Cl)  (•  ’Cl  _T»C)  ))l) 

(-/>  C (•  (DEN  ’«C)  ’C) 

(RNO  (-/>  C (/>  TG  IBM) 

(0-FERTURE  ’»P 

(RANGER  V-CRIN  VERY-HIGH))) 
(-/>  G (RNO  (/>  ’C  SB) 

(/<  ’C  SBBB)) 

(0-FERTURE  »»P 

(RANGER  V-GRIN  HIGH) )) 

(-/>  G (RNO  (/>  'G  1) 

(/<  'C  IBB)) 

(0-FERTURE  T*P 

(RANGER  V-CRIN  nOOCRATED) 
(-/>  C (•/.  ’C  1) 

(0  'EATURE  »»P 

(RANGER  V-CRIN  LOUD)))))) 


I ’CAIN*  RLONE  HERNS  V-CAIN  ANO  P-CRIN 
(DCrniR  CAIN-SHRRO 

l-/>  A (O-SHRRO  ’*P  l\  (_»*V)  (.  (CAIN  (|»»|  .»*V) ) 

_nC)l) 

(RNO  (O-SHARO  ’4P  (\  (_’*V)  (•  (V-CRIN  (|»»|  _>*V)) 

.’♦Oil 

(-/>  C (ANO  (•  (•  ZB  (LOG  (OEN  .’*C)I)  ’RGI 
iCONVERT  TO  DECIBELS 
(.  (OfN  »fPC)  TPO) 

(O-SHARO  ’*P 
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(\  (.  (P-CfltN  ((>'1 

_npc))))))) 


(OtFntB  IMPUT-Z-SHflPO 

(-/>  n (0-5MBP0  ’.P  I\  (.  (IHPUT-Z  (|”|  _’4V)) 

J*ZU) 

(-/>  C (.  (OEN  ’«Z)  ’Z) 

(BHD  (-/>  G (/>  ’Z  3.eE5) 

(D-FEBTURE  ’4P 

IRBNCER  INPUT-Z  VERY-HICHl) t 
(-/>  C (BND  (/>  ’Z  1.5E3) 

(/<  ’Z  S.BESn 
(D-FEBTURE  ’4P 

IRBNCER  INPUT-Z  HIGH))) 

(-/>  C (BNO  (/>  ’Z  588) 

(/<  ’Z  2.8E3)) 

(0-FEBTURE  ’4P 

IRBHCER  IHPUT-Z  nOOERRTEl )) 
(-/>  C (/4  ’2  1888) 

(0-FEBTURE  >4P 

IRBHCER  IHPUT-Z  LOU))))))) 


(OEFHIB  OUTPUT-Z-SHBRO 

l-/>  B (O-SHBRO  ’«P  IV  (_?4V)  (•  (OUTPUT-Z  (|”|  _»4V>) 

_’4Z)) ) 

(-/>  C (.  (DEN  ’4Z)  ’Z) 

(BNO  (-/>  C (/>  ’Z  ).8E6) 

(O-FEBTO'E  ’4P 

IRBHCER  OUTPUT-Z  VERV-H)CH))) 
(-/>  C (BNO  (/>  ’Z  1.8E5) 

(/<  I.SE6I) 

(0  FfflTURE  ’.P 

IRBNCER  OUTPUT-Z  HIGH))) 

(-/>  C (BNO  (/>  ’Z  1.8E4) 

(/<  ’Z  I.5E5)) 

(D-FEBTURE  ’4P 

IRBNCER  OUTPUT-Z  nOOERBTED) 

(-/>  C (BNO  (/>  ’Z  188) 

(/<  ’Z  1.5E4)) 

(D-FfBTURE  ’4P 

IRBHCER  OUTPUT-Z  LOU) 1 1 
(-/>  C (/«  ’Z  ?88) 

(0  FfBTURE  T.P 

IRBHCER  OUTPUI-Z  VERY-LOUl ) ) ) ) I ) 

iSOUHCCi  UBTSOH  (19781,  P.  68 


(SMBRDS  RECBROIHC  SICHBl  CONVERSIONS  OUST  BE  EXPLOOEO  SPECIHILY 

(OEFfllB  CONVERT -EXPLODE 

l-/>  fl  (/iTBSF-BCTIOH  7T  (0-EXPlODE  ’4P)) 
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(0-SHRRD 

(CONVfRT  (|”|  _’*V)  _7.Q  _5»R)I) 
(EXISTS  (Tl) 

(AND  (STflST  ’Tl  ’T  <> 

(\  ()  (CVT-EXPLOOE  no  ’♦*)  ) 

<>) 


GENERAL -nP«) 


(/sflBIN  ’Tl  ’T) 

(-/>  fl  (SIC-FEflTURE  ’*Q  ’*R  ’.FERTURE) 
(0-SHRRD  ’*P 
(\  (_’.V) 

(SIC-TRRNS  _’«V 

.’♦FERTUREH  )))  ))l 


[THERE  RRE  TUO  URYS  TO  00  THIS-- 


(OEFniR  CVT-EXPLODE-1 

I/iTO-00  ’TRSr  (CVT-EXPLOOE  ’*0  ’*R»  <> 

(freq-oohrin-rephrrse  ’*0  ’.rid 


(DEFtllR  CVT  EXP100E-? 

i/iTo  no  ’TRs>  (CVT  rxpioof  ’.o  ’*r)  <> 

(Tlnr  DOHRIN  REPHRASE  ’.0  ’4R)I) 

I BASIS  ON  UHICH  TO  CHOOSE  ONE  OR  THE  OTHER 

(OEFulr  CVT  choice 

I/iRNTEC  (NOT  (/tCHOICE  ’C  EXEC 
(/: TO-DO  _’«TRST 

(CVT-EXPLOOE  _’»»0  _’*.RI  <» 
_’«.nETHOOIU 
(./>  A (/tOPTION  ’C  'Al 

1/iTO-OO  .’♦TASX 

(CVT-EXPLOOE  _’*»Q  _’«*R) 
« > 

(FREO-OOnAIN-RE  PHRASE 

_x..Q  _’«*R)|) 

(-/,  A (/.-OPTION  ’C  ’A? 

I/i TO-DO  _’.TASt 

(CVT-EXPLOOE  .’♦♦0  _’*»R) 


(TIHE-OOnRIN-REPHRASE 

_’*.Q  _’4*R)1) 

IF  OUTPUT  RELATION  DOESN’T  HENTION  INPUT,  TRXE  FREOUENCX-OOnAIN 
(AND  (-/>  C (AND  (/■•  (DEN  ’44R) 

(\  (_’4svi  _’«svr» 

_’4lOOXI ) 

(NOT  (CONTAINS  ’*BODY 

1|”|  _’*SVll>n 
(/iRULE-IN  ’AD) 

IF  INPUT  PREDICATE  IS  TRIVIAL,  TRFE  TlnE-DOHRIN 

(-/>  C (AND  (/!•  (DEN  ’»4Q) 


■d 


ApfipnrI  i y 


o 


♦ 


t\  (_’»V)  _’4BOOV)) 
(wr  fcoNffliws  '«B0or 
I|”l  _7«V)))) 
(/:RULE-IN  ’B2)) 

I FOR  VERY  HIGH  FREQUENCIES,  TinE  DOnRIN  WON'T  UOR* 

(-/>  C (RND  (/tSUBTRSF  (OEN  ’«TflSF) 
’SUP) 

(/iTRSF-RCTION  ’SUP 

(O-EXPLOOE  ’«P)» 
(/,.  T/iENRB-STRTUS 
’SUP  I 
RCTIVE) 

(D-FEBTURE  ’*P 
IRHNCER  FREQ-OP 

VERY-HIGH) )) 
(/iRUlE-OUT  ’B2))))») 

CEHERHL  OP») 


I FREQUENCY-OOnsiN  REPHRASING  INFO 


(DEFrtLR  FREQ-DOn-REPH-DO-l 

l/iTO-00  ’TflSF  (FREQ-OOriRlN-REPHRnSE  ’*0  ’♦R)  <> 

(/.'SEO 
l/;F INO 

(\  (.FPT) 

(EFISrs  (FPl  FP2  FPT) 

(FORPU  (SI  S2) 

(inpi lES  (AND  (IS  signal  ’SI) 

((OEN  ’.Q)  ’SI) 

(IS  signal  ’S2) 

((DEN  ’.R)  ’SI  ’S2)) 

(AND  (./>  ’ (FREQ-PICTURE 
(TFUN  ’Sll) 

’fPl) 

(./>  ' (FREQ-PICTURE 
(TFUN  ’S2)) 

’FP2) 

(FREQ-PIC-TRANS  ’FPl  ’FP2 
’FPT) 

(./>  • (OEN  ’»FPT)  ’FPTD) 


)))) 

(\  (FPT) 

(/!  INFIR  '(SIG  FIATURI  ’.Q  ’.R  IFREQ-TRANS  _’»FPTI) 
.>)  Ill) 


iCENERATING  frequency  DOHA  in  TPANSFORnATIONS 


(DEFnCA  NFREQ-PICS  FILTER 

l/iCONSEQ  (NOT  (FREQ  PICS-FILTER  ’FPl 

<(FF  ’FREQ  ’11121  '/’FP2,  ’C)) 


d 


(NOT  (fOROU  (ini) 

(NOT  (ELT  (EE  ■’FREQ  ’LUl)  ’EPD)  ))1) 


(OtFMLR  FREQ-TRBNS-lOU 

I/iCONSEQ  (EREQ-TRRNS  'EP-IN  ’EP-OUT  (LOU-PRSS  ’til) 

(NOT  (RND  (EREQ-PICS-EILTER  ’EP-IN  ’EP-OUT  >FP-C0NE) 
(EORRLL  (EL  F) 

(RND  (EQUIV  (EIT  (EE  ’F  TEL)  ’EP-CONE) 
(EORRLL  (ELI  Ell 
(II1PLIE8  (ELT  (EE  ’El  ’ELK 
’EP-CONt) 

(/>  »E  ’ED)  )) 

(/i.  ’(1 

(HR*  ’EP-CONE 
(\  (E  C) 

(/>  (FE-FREQ  ’E( 

(EE-EREO  ’CD 
))))  ))))) 

;SiniLRRlY  FOR  HICH-PRSS  RNO  BRND-PRSS 

IDEfnLR  EREO-PJCS-EUTEP-J 

IEREQ-PICS-FILTER  ’EPl  <>  ’EPll) 

(OEEHLR  FREO-PICS-EILTER-2 

t/:CONSEQ  (ERf  Q-P ICS-E  |L  TER  ’EPl  <(EE  ’FREQ  ’LRZ)  IP’EP2>  ’C) 
(NOT  (RNO  (ELT  (EE  ’FREQ  ’END  ’EPD 

(.  (EE-SHRPE  ’LHD  (FE-SHRPE  ’Lt12D 
(EREO-PICS-FILTER  (DEL  (EE  ’EREQ  ’LRl)  ’EPD 
’EP2  ’C)))D 

iTYPCS  Of  EREQ-ERRNS:  (LOU-PRSS  ICUTOffp,  (HJCH-PflSS  |COTOEE|), 

I (BRNO-PflSS  |CUTOEE|),  (f11«  |S  ICNRL -PRED  | ) (ROOULRTE . . . ) 

(OEEriLfl  LOU-PRSS 

t/iRNTEC  (NOT  (O-SHRRO  ’*P 

l\  (_’»V)  (SIO-TRRNS  (|”|  _’»V) 

(EREQ-TRRNS 

(LOU-PRSS  _’*CUTOEED)ID 
(CORE-OEV-TYPE  ’.P  (LOU-PRSS-E ILTER  _’»CUTOEFDD 


(OEEfILR  MICH-PRSS 

t/iRNTEC  (NOT  (0-SHRRD  ’.P 

t\  (_’*V)  (SIC-TRRNS  (|”|  _’»V) 
(EREQ-TRRNS 

(HICH-PRSS  .’♦CUTOEEDDD 
(CORE-OEV-TYPE  ’*P  (HICH-PRSS-EILTER  _’«CUTOEFI )l ) 


iCHOOSINC  OEV-TYPES  — 
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(OEFfllR  UNERR -CROUP INC 

t-/>  R (/:CH0ICE  ’C  ^TSF  ICORE  DEV-TYPE  _’«»P  _’**DI ) 

<-/>  R (QUIESCENCE  ?C> 

(-/>  C (RND  (/(OPTION  ’C  ’Rl 
ICORE  DEV-TYPE 

I_’**P)  I_’**01in 
(/(OPTION  K ’H2 

ICORE -OEV-TYPE  I_t»»P)  l_n.02))) 
(LINERR-OEV-TYPE  (DEN  (DEN  ’♦♦02))) 

) 

(/(RULE-TOCETHER  «’fll  ’R2> 

ICORE -DEV-TYPE  _’♦♦? 

ICROUP  _’^^02>1I)))I) 


[CROUPS  DRY  BE  EYPRESSEO  RS  SEVERRL  FINDS  OF  CflSCflOE 

(OEFNLR  HR) E -CROUP- I 
l/(CONSEQ 

(/(TO-DO  ’T  (tin*E  (CROUP  < ’*  ’Y  if’Z>))  <’NR)1E> 
(/(SEQ  (REQUIRE  (CROUP  '’OT-REST)) 

(\  (C)  (nO>E  (CflSCRDE  ’OTl  ’O)  ))) 

(NOT  (RND  (ELT  ’OTl  ♦’*  ’Y  (/’Z>) 

(/(.  ’OT-REST  (DEL  ’DTI  <’X  ’Y  i»’2>))))I 

CENERRL-OPt) 


(OEFNIR  MRrE-CROUP-2 

(/(TO-DO  ’T  (HfltE 
(riR)E  (CRSCROE 


(CROUP  «’0I1  ’0T2>))  <’NRI1E> 
’OTl  ’0T2))I) 


(OEFNIR  NRrE-CROUP-3 

(/[TO-DO  ’T  (NRIE 
(NR)E  (CRSCROE 


(CROUP  <’0T1  ’0T2>)I  «’NflNE> 
’0T2  ’OTl)  ID 


iRNPlIFIER  IS  R HIDE  ( "SUPEROROINOIE ")  CRTECORY.  FOR  UHICM  THERE  RRE 
I SEVERRL  SPECIFIC  TYPES 

(OEFNIR  RNP-OEV-TYPE  ISUPERORDINRTE  OEV-TYPE  RNPUFIE*)) 

(OEFNIR  SUB  CE  ISUB  DEV-TYPf  CE  RNPUFIERI) 

(OEFNLR  SUB-CC  ISUB-OEV-TYPE  CC  RNPUFIERI) 

(OEFNLR  SUB-C6  ISUB-OEV-TYPE  CB  ROPLIFER)) 

I IF  NODERRTE  V-CRIN,  CONOON  ENITTER 
(OEFNLR  NOO-V-CRIN 

(-/>  R (/iTRSr-RCTION  ’TSI  (I1R)E  RNPLIFIER)) 

(-/>  fl  (/(SCOPE  ’PTSr  ’Tsn 

(-/.  R (/(POLICY  ’PTSF 

W mn  IRRNCER  V-CR’N  Ylt>DERR1{)n 
(/(lO-OO  ’TSI  (NRFE  RNPLIFIER)  «’OEV> 
(NRtE  CE))))I 


CENERRL  OPt) 


I IF  HIGH  V-GfllN,  sons  MNO  OF  N-STRCE 
(OtFnin  HiCH-v-cniN 

l-/>  R (/sTHSK-flCriON  ’TS»  (riRFE  RnPUFIERI) 

(-/>  fl  (/:SCOPE  ’PtSF  nSF) 

(-/>  R (/.POUCY  ’PISF 

(D-NOTE  (RRNCER  V-CRIN  HIGH))) 
(/sTO-00  nSF  (RRFE  RRPUFIER)  <’OEV> 
(mWE  N-STRCEI)))I 

CEMERRL-OP*) 


I IF  VERY-HIGH,  OP-flnP 
(OEFHLR  VERY-HIGH-V-GRIN 

I-/>  R (/iTflSF-RCTION  ^TSF  (HWE  flnPLIFIER)) 

(-/>  R (/iSCOPE  ’PTSr  ’TSF) 

(-/>  R (/:POLICY  ’PTSF 

(O-NOTE  (RRRGER  V-CflIR  VERY-HIGH))) 
(/iTO-00  ’TSK  (HRFE  RtlPLIFIER)  <YOEV> 
(HRYE  OP-flnp))))I 

GEHERflt-OP») 


I IF  VERY  LOU  FREQ  OF  OPERRIION  (E.C..  OC)  — OIFF  RHP 
(OEFHLR  VERY-LOU-FREQ 

I-/>  R (/i  IR5F-RCTION  ’TS»  (Hfl»E  RnPLIFIERU 
(-/>  R (/iSCOPE  ’PTSF  ’TSF) 

(-/>  R (/rPOLICY  ’PTSF 

(O-NOTE  (RRNCER  FREQ-OP  VERY-LOU))) 
(/;T0-00  ’TSF  (flRFE  RTIPLIFIER)  <’OEV> 
(HRFE  OIFF-RnP))))) 

CENERRL-OP*) 


I IF  HIGH  INPUT  2.  UP  CC 
(DEFflLR  HIGH-INPUT-? 

I-/>  R (/I  TRSF-RCTION  ’TSF  OIRFE  RflPLIFIERM 
<-/>  R (/iSCOPE  ’PTSF  ’TSF) 

(-/>  R (/iPOLICY  ’PISF 

(O-NOTE  (RRNCER  INPUT-2  HIGH) ) ) 
(/iTO-00  ’TSF  (HRFE  RRPLIFIER)  <’0£V> 
(RRFE  CC))))I 

GENERRl-DP*) 


I IF  HIGH  POUER  GRIN,  UP  COnP-SYH  RNO  PUSH-PULL 
(OEFmR  HICH-POUER  GRIN 

L-f-,  R </!  TRSF-RCTION  ’TSF  (HR)  t RnPUFLEtO 
(-/>  R T/iSCOPE  ’PTSF  ’TSF) 

(./>  R (/iPOLICY  ’PISF 

(O-NOTE  (RRNCER  P-CRIN  HIGH))) 

(RNO  )/iTO-00  ’TSF  (HRFE  RTIPLIFIER)  <’DEV> 
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I 


I 


CtNlRUL -DP») 


(nprf  conp-srn)) 

(/:T0-00  ’ISK  <n«rE  RnPUFIER)  <’OEV> 
(nPEE  PUSH-PUU ) ) ) ) II 


1 

i 

I 

I 

I 

I 

( 


A 


I IF  LINEPRITY  RtOUIREO.  CE 
(OEFflin  linerritv 

(-/>  B (/;TflSF-flCTIOR  ’TS»  (flBIE  BfiPLlFIERt) 

(-/>  B (/:SC0PE  ’PT5»  ’TSF) 

(-/>  fl  (/iPOLICY  ’PTBSt  ’TSF 
(O-ROTE  IINEBRU 

(/jTC-00  ’TSF  mBFE  BfIPllFIER)  «’OEV> 
(HflFE  CEI)»») 

CEHERBL-OP*) 

I IF  nORE  THBN  ONE  TYPE  BPPEBRS,  B CHOICE  IS  IN  OROt* 

(DEFnifl  CHOOSE-BnP 

t-/>  B I/sCHOICE  ’C  EKEC 

l/i  TO-DO  _nTBSr  (tlBKE  RNPUFIER)  <_»*N«nE> 
J.nETHOOl  I 

(-/»  C (/!.  (DEN  ’.TflSn  ’BRP-TBSFI 
(BNO 

(/iPFT  CHOOSE -BMP-PFT 

(’C  ’BOP-TBSF  ’tTBSE  ’♦NflllE  ’♦HETHOO) 
(-/>  B (/:QUIESCENCE  ’C) 

(/:PFT  QU5 -CHOOSE -BNP -PICT 
(»C  TRHP-TBSF  ’♦TflSr 
VHflnE  ’♦HETHOOmi 
(-/>  c (/: SCOPE  ’PTsr  ’Brtp-Tflsn 
TRUE)) II 

CENERRL-OP») 


lIF  HIGH  POUER  BNO  UNEBRITY  BRE  REQUIRED,  REPLBCE  POUER-BHP 
I OPTION  UITH  LINERRIZEO  POUER-RBP 

(OEFntB  ITNEBR-POUER 

l-/>  B (/iSrnPE  ’PT5M  ■’BnP-IBSF) 

(-/>  C (BNO  (/iPOUCY  ’PISFl  (O-NOTE  LINEBRI) 
(/iSCOPF  ’PTSF2  ’flnP-TflSF) 

(/iPOUCY  ’PTSF? 

(D-NOTE  (RBNGER  P-CBIN  HIGH))) 
(./>  ' (DEN  ’.PTSrZI  >PTSF2)) 

(-/>  B (/[OPTION  K ’Bl 

I/: 10-00  _’*TflSr  (HB)E  BBPIIFIER) 
»_T<NRftEj  (NBFf  _T»OI)I) 


(■/>  G 

(OPT-SUPPORT  >R1 

1/iPOllCY  _nPTRSF2 


1 
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I 


(/tHUlt-IOCETHfll 

(/iTO-W  (twrt  HnPLIFIER) 

(/iSEO  (WWE  _»»0T> 

(\  OX) 

«/iOO-BLL 
<(LINERRIZE  ’X)> 
(/lOUIPUT  <7X>))  ) 

))))>)) 

CHOOSE -RHP -PET) 


(QUIESCENCE  PM 

lOirrCRENTIRL  OIRGNOSIS  8ETUEEN  CE  RND  N-STRCE 
(OEEHLR  DIfF-CE-N-STRCE 
(-/>  R (/(QUIESCENCE  ’C) 

(-/>  C (RNO  (/(OPTION  ->C  ’Rl 

l/(T0-00  J.TRSX  (RRXE  RNPLIFIER)  <7_4NRHE> 
(Hfl)E  CE)I) 

(/(OPTION  ’C  ’R2 

I/(T0-00  _nTRSK  (RRXE  RHPLIFIER)  <_T*NRnE> 
(HRFE  N-STflCE)l)) 

(RND 

(-/>  C (RNO  (/(SCOPE  ’PTSK  ’RflP-TRSF) 

(/(POLICY  ’PTSX 
(O-NOTE 

(RRNCER  BRNOUIOTH  HIGH)))) 
(/(RULE-OUT  ’Rin 
(-/>  C (NOT  (EXISTS  (PTSX) 

(RNO  (/(SCOPE  ’PTSX  ?RRP-TRSX) 
(/(POLICY  ’PTSX 

(O-NOTE  (RRNCER  BRNOUIOTH 
HIGH)))) 


(/(RULE-OUT  ’R2))))) 

CHOOSE-RHP-PFT) 


)) 


I (IF  ONE  OPTION  URS  SUGGESTED  RECRUSE  OF  ITS  INPUT-Z  (E  C., 

* 1 COnnON-COLLECTOR) . RND  RNOTHER  FOR  SONETHINC  ELSE, 

} V3U  HRY  CRSCROE  THER 

(DEFHLR  INPUT-CRSCROE 

l-/>  R (/(OPTION  ’C  ’R1 

|/(TO-DO  _’*TRSF  (Hfl)E  RHPLIFIER)  <_74N> 

i (HRFE  _Y4GTUI) 

(-/>  C (OPT-SUPPORT  ’R| 

1 l/iPOLICY  _)4PTRSX 

> (O-NOTE  (RRNCER  INPUT-Z  _’4RRN))I) 

(-/>  R 

(/(OPTION  7C  ’RZ 

l/iTO-OO  _>4TRSX  (HRFE  RRPLIFIER)  <_74N» 
iflRXE  .740T2II) 
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CHOOSE -BtlP-Ptn 


(-/>  C (HOT  (.  tri  JR2)) 

(/!PUIE-I0CETHER  «’fil  ’B2> 

1/iTO-OO  .NTRSK  (HflCE  BriPLIFIER) 
<_T4N> 

(HflrE  (CBSCBOE  _’*0T1 
_’*0T2 
))l))))) 


(OEFOLB  OPT-SUPPORT  (-/>  C (BMO  (/tOPTIOH-SUPPORT  ’OPT  ’FfllfiS) 

(EIT  ’.F  ^FtlLBS) 

(OR  (!.  T»F  7»S1 

(SUPPORTS  ’»S  T4F)»1 
(OPT-SUPPORT  ’OPT  NS)) 
CEMERBL-OP*) 


(OEFULR  SUPPORT-OEEN  l-/>  C (OHO  (/:00  ’*S  ’P  M ’♦E2» 

(OR  (:•  T4FI  T4S) 

(SUPPORTS  ’4FI  T,S)H 
(SUPPORTS  ’4FI  ’tfitJ 
CENERBL-DP*) 


(OEEHLR  HBrE-CBSCB'JE 

l/.TO-OO  ’TBST  (f1B*E  (CBSCBOE  ’DTI  ’0T2))  <’HEUOEV> 

(/:Ot  -SUBNET  (CBSCBOE -PLBN  ’OTl  ’OT2)  .CBSCBOE -NBnE>»l ) 

(OEETHB  CBSCBOE-PIBN-NET 

t-/>  B (/iPlBN-IMSTBNCE  ’PI  (CBSCBOE -PLBH  -OTl  ’OT2>  ’SUP) 

(BNO  (STBSF  (nB>ER-l  ’PJ)  ’SUf  <> 

(\  0 (HB»E  ’OTl»  ) <MF|RST-OEV  ’PI)>) 

(STBSr  (f1B»ER-2  ’PI)  ’SUP  «> 

(\  O (HBIE  ’DT2)  ) <> (SECOHO-OEV  ’PI)>) 

(STBS)  (CRBBBER  ’PI)  ’SUP  <> 

('  0 

(CRBBBB  (\  (X) 

(noiN-oEv-TrPE 

’K  (CBSCBOE  ’OTl  ’OT2))  ))  ) 

(CBSCBOE -NBOE  ’Pl)>) 

(STRSF  (COUPLER  ’PI)  ’SUP 

<’(FIRST-OEV  ’PI)  MSECONO-OEV  7PI)> 

(\  (01  02)  (COUPLE  ’01  ’02)  ) 

<>) 

(STBS)  (COdPONEHTS  ' BHCR  ’PI) 

«’ (CBSCBOE  NPHE  ’PI) 

’(FIRST-DEV  ’PI)  '(SECOHO-OEV  ’Pl)» 

(\  (C  01  02) 

(/iIHFER  '(COnPOHEHTS  ’C  <’01  ’02>)  <>)  ) 

<>) 


(/.nflIH  (CRBBBER  ’PI)  ’SUP))I 
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t 

I 


CEHCRW.-OP*) 


(USE  THE  HOST  CENEROL  VERSION  OF  R CIRCUIT  IN  R CRSCROE 

(OEFniR  COUPLE-GENERRC-l 

l-/>  R (/iCHOICE  ’C  EXEC 

I/iTO-00  (riR>ER-l  _’*PIt  (nRTE  _T«OT)  <_»«OEV> 
_’*URY1 ) 

(-/>  C IRNO  (./>  ’(DEM  nOT)  ’OT) 

(nOST-CENERRL-SPEC  ?OT  ’SPEC-OTl 
(./>  ’ (OEN  ’«SPEC-OT)  ?SPEC-OT)) 

(-/>  R (/lOPTION  ’C  ’R 

C/iTO-00  (NflFER-1  _’»PII  (IHWE  _’»OT) 
<_?*0£V> 

(HRTE  _»*SPEC-OT)l) 

(/iRULE-IN  XRini) 


(OEFnCfl  COUPLE-GENERRL-2 

I-/>  R (/:CHOICE  ’C  EXEC 

l/i  TO-DO  (llfirER-2  _’*PI)  (NRFE  _»*OT)  <_»»OtV> 
_%MRV) ) 

(-/>  C (PNO  (•/>  ’(OEM  ’*OT)  ’OT) 

(nOST-GENERRL-SPEC  ’OT  ’SPEC-OTI 
(./>  ’(OEM  ’«SPEC-OT)  ’SPEC-OTM 
(-/>  R (/.OPTION  ’C  ’R 

l/.TO-OO  (HRFER-2  _»*PI)  (ORTE  _’»OT) 
<_’*OEV> 

(NR»E  .’♦SPEC-OTM) 

(/iRUCE-IN  ’R)))|) 


t 

! 

I 

I 

I 

I 

i 


iCIRCUIT  RITERRTION  ACTIONS 


(OEFDLR  FIXING-CMRNCES-TOPOIOCY  ITOPO-CHRNCE-RCTION-FUN  FIX)) 


(OErncR  vs-Fix-v 

(/iTO-OO  ’TflSr  (FIX  ’(V  ’NODE))  <> 

(CONFIG  (VOLTAGE -SOURCE) 

(\  (VS) 

<(TRniNS-CONNECT  (ft  ’VS)  ’NOOE)>  III) 


(OEFniR  VD-FIX-V 

l/iTO-DO  ’TASK  (FIX  '(QUIESCENT  IV  ’NOOCMI  <> 
(CONFIG  <VD  NODE  NOOE> 

(LRUBDR  (VO  Ml  N2) 

♦(CONSTRAIN  <’(V  ’Nil  ’(V  ’NOOCI> 

(\  (VI  VI  (/.  ’VI  ’V)  II 
(CONSTRAIN  ,'(V  ’N2I  ’(V  ’NOOE)> 

(\  (V2  V)  (/>  ’V  ?V2)  )) 

» 

9 

I; 


I 
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(NOOtS-nfRCE  ’N1  (TOP  ’VO)) 
(NOOES-riERCf  'H2  (BOT  ’VO)) 
(NODES-nERCE  'NODE  (HIO  ’VO))>  ))I 

CCNERflL-OP») 


(OtrnLB  OIE-MK  l/iTO-DO  ’TflSE  (FIX  • (-  ’XI  ’X2))  <> 

(/iOO-fllL  »(FIX  ’’XI)  (FIX  ’’X2)>)I) 


iBinSINC 

(OEFOLR  BlfiS-CHONCES-TOPOLOCV  ITOPO-CHR)tCt-nCT|0)l-fUN  BIBSl) 

(OCFOLR  BJT-6IRS 

l/sRNJEC  (NOT  (OEV-TVPt  ’Q  BJT)) 

(/iTO-00  ’TRSr  (BIOS  ’Q  RCTIVt)  <> 

(/;00-SUBNET  (CENERRL-BIRS-PLRN  ’Q)  ’TRSr  <>)))) 


(OEFflLR  BJT-B IRS-NET 

I/iRNTEC  (NOT  (/;  PIRN- INSTONCE  ’PI  (CENERRL-BIRS-PLRN  ’Q)  ’SUP)) 
(RNO  (STRSF  (VBE-FIXER  ’PI)  ’SUP  <> 

(V  ()  (FIX  ■(-  (V  (BRSE  ’Q))  (V  (ENI  ’Q))))  ) 

<>) 

(STRSr  (CB-BinSER  ’PI)  ’SUP  <> 

(\  ()  (REVERSE-BIAS  (CB-JUNCTION  ’Q)>  ) <>) 

(STRSF  (IC-FIXER  ’PI)  ’SUP  <> 

(\  ()  (FIX  ’ (I  (COL  ’0)))  ) <>) 

(/:NfllN  (VBE-EIXER  ’PI)  ’SOP) 

(/iMRIN  (IC-FUER  ’PI)  ’SUP))I 

GENERAL -0P«> 

(OEFNCR  TYPICRL-BJT-ONE-STBCE-BIRS 
I-/>  R (/(PLRN-INSTBNCE  ’PI 

(TYPICRL-BJT-ONE-STRGE-BIRS-PLRN  ’Q)  ’SUP) 

(RNO 

(STfiSX  (BVO  ’PI)  ’SUP  <> 

(\  ()  (ACQUIRE  VO)  ) <’(BVO  ’Pl)>) 

(STRSF  (SUPPLY  POUER  ’PI)  ’SUP  «> 

(\  ()  (REQUIRE  VS)  ) <’ (POHER-SUPPLY  ’PI)>) 

(STRSF  (RESIS-CETTER  ’PI)  ’SUP  <> 

(\  ()  (ACQUIRE  RESISTOR)  ) <’ (RE  ’Pl)>) 

(STRSF  (BASE-SETTER  ’PI)  ’SUP  <’(BVO  ’Pl)> 

(\  (VO)  (TRniNS-CONNECr  (BRSE  ’0)  (NIO  ’VO))  ) 

<>) 

(STRSF  (COLLECTOR-POWER  ’PD  ’SUP 
<’ (POWER-SUPPLY  ’Pl)> 

(\  (PS)  (OEV-INSERT  ’PS  (CNOOE  ’0) 

(#2  ’PS) 

(NOOE-TERNINALS  (CNOOE  ’Q)l 
(#1  ’PS)  <>)  ) 

<>) 

(STRSF  (ENITTER-flUNGER  ’PI)  ’SUP  <’(RE  ’PI)> 
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(\  (P)  (OEV- INSEPT  TP  (EMOOE  tQ) 

Ifl  Tp)  <(Cni  TO)> 

(#2  TP) 

(OEL  (EfU  TQ) 

(NOOE-TEPniNRES  (ENOOE  ’Q))))  ) 

<>) 

•PEOUCE  <IBVO  ’PI)  (8BSE -SETTER  ’PI)> 

(VBE-FIXEP  ’PI)) 

(REDUCE  <(SUPPLY-POUEP  ’PI)  (COUECTOP-POUEP  ’PD> 
(CB-BIBSEP  ’PI)) 

(REDUCE  «(PESIS-CETTEP  ’PI)  (EtIITreP-nUNCER  ’PI)> 
(IC-nXER  ’PI))  )I) 


(OEFNLfi  SPEC-TYPICBE-BJT 

ISPEC-SCHEBR  (TYPICRL-BJT-DNE-STRCE-BIRS-PLRN  ’0) 
(CENERRL-BIRS-PLRM  ’0)1) 


iCOUPlING  HRS  BEEN  SPEC  IRC  ITED  TD  BJT  RnPlS. 

(OEFnLR  COUPE INC-CHRNCES-TDPOIOCY  ITOPO-CMRNCE-RCTION-FUN  COUPLED 
(OEFHER  COUPLE-OO-l 

I/i TO-DO  ’TflSr  (COUPLE  ’01  ’PORTI  ’P0RT2  ’02)  <> 

(/:00-SUBNET  (CENEPBL -COUPL INC-PLRN  ’01  ’POPTl  ’P0PT2  ’02) 
’TflS)  <>)I) 

(DEFRER  COUPLE-NET 

I/iRNTEC  (NOT  (/iPLBN-INSTBNCE  ’PI 

(CENEPfll -COUPL INC-PLRN  ’01  ’POPTl  ’P0PT2  ’02) 
’SUP)) 

(RNO  (STRST  (SICNRL-nEOlUn-CMOOSE  ’PI)  ’SUP  <> 

(\  () 

(/iFINO 
(\  (ID 

(ELT  ’R  <VOETRCE  CUPPENT>)  ))  ) 

<• (nEOiun  ’Pi)>) 

(STRSF  (COUPLE -TYPE -CHOOSE  ’PI)  ’SUP  <> 

(\  () 

(/iFINO 
(\  (CT) 

(ELT  ’CT 

^DIRECT  CRPRCITIVE 
INOUCTIVE>)  D ) 
.’(COUPLE-TYPE  ’PI)>) 

(STRSF  (CONVEPT-POPT-1  ’PI)  ’SUP  .’(REOIUR  ’PI)» 
(\  (R)  (POPT-CONVIPT  ’POPTl  ’R)  ) 

<>) 

(STRSF  (CONVERT-POPT-2  ’PI)  ’SUP  <* (REOIUR  ’PI)> 
(\  (R)  (POPT-CONVEPT  ’P0PT2  TR)  ) 


I 


(STflSk  (CONNECTOR  Tp|)  ?SUP  <’ (COUPLt-TYPt  ’RI)> 
(\  (TYPE) 

(PORTS  connect  7P0RT1  ’PORT?  ’TYPE)  ) 

<>) 

(/!  successor  (SICNOL-ntOlUn-CHOOSE  ’PI) 

(CONVERT-PORT-1  ’PD) 

(/tSUCCESSOR  (SICNRL-nCOIUn-CHOOSE  ’PI) 
(CONVERT-PORT-?  ’PD) 

(/i  SUCCESSOR  (CONVERT-PORT-1  ’PD 
(CONNECTOR  ’PD) 

(/tSUCCESSOR  (CONVERT-PORT-?  ’PI) 

(CONNECTOR  ’PD) 

(/irmiN  (CONNECTOR  ’PI)  ’SUP) 

)) 

CENERRL-OP*) 


(OEFnLR  COUPLE-BEEORE-BinS 

l-/>  n (/iTRSE-BCTION  ’CT  (COUPLE  ’01  ’PRTl  ’PRT?  ’0?)) 
(-/>  C (BNO  (CONPONENTS  ’01  ’OICS) 

(COnPONENIS  ’0?  ’0?CS) 

(OR  (ELT  ’Q  ’OICS)  (ELT  ’Q  ’0?CS)) 
(nOIN-OEV-TYPE  ’Q  BJTD 
(/tSUCCESSOR  ’CT  (BIRSER  ’Q  ’NOOE))))) 


iSPECIEIC  SITURTIONS  — 

(OErnin  couple-ce-k-hints 

l-/>  R (/i  TRSE-RCTION  ’CT  (COUPLE  ’01  (OUTPORT  ’01)  ’PRT?  ’0?)) 
(-/>  C (OEV-TYPE  ’01  CE) 

(/iP)T  CE-COUPLE-HINTS  (’CT  ’01  ’PRT?  ’0?) 
(/iTO-00  ’CT  (COUPLE  ’01  (OUTPORT  ’01) 

’PRT?  ’0?)  <> 

(/i 00-SUBNET 

(CE-OIR-VOl-COUPLE  ’01  ’PRT?  ’0?) 

<>)) 

(/:T0-00  ’CT  (COUPLE  ’01  (OUTPORT  ’01) 

’PRT?  ’0?)  <> 

(/! 00  SUBNET 

(CE-OIR-CUR-COUPLE  ’01  ’PRT?  ’0?) 

<>)) 

UiJO-00  ’CT  (COUPLE  ’01  (OUTPORT  ’01) 

’PRT?  ’0?)  <> 

(/lOO-SUBNET 

(CE-CRP-VOl -COUPLE  ’01  ’PRT?  ’0?) 
<>)))))) 


(OEEHLR  C0UPLE-CC-*  HINTS 

|./>  R (/iTflSr-RCTION  ’CT  (COUPLE  ’01  (OUTPORT  ’01)  ’PRT?  ’0?)) 
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»-/>  C (OtV-TVPt  -Ol  CC) 

(/■.PH  CC-COOPIE-HINTS  (’CT  >01  ’PHT2  >02» 
l/i  TO-DO  ’Cl  (COUPLE  ’01  (OUTPOPT  ’01) 
’P«T2  ’02)  <> 

(/lOO-SUSNET 

(CC-OlP-VOL -COUPLE  ’01  ’PPT2  ’02) 
<>)))))) 


(OCEm.«  CE-OIR-VOL-COUPIE-PLBN 

(-/>  B (/;PLRH-INSJPKCi  ’PI 

(CE-OIR  VOL-COUPLE  ’01  ’PRT2  ’02)  ’SUP) 

(BNO  (•/>  MtlEOlUn  ’PI)  VOLTflCE) 

(./>  • ICOUPLE-T»PE  ’PI)  DIRECT) 

(/iREOUCrO  (SICNBl-nEOlUn-CHOOSE  ’PD) 

(/iREDUCEO  (COUPIE -TYPE -CHOOSE  ’PD) 

(STBSr  (CET.RESISTOR  ’PI)  ’SUP  <> 

(\  ()  (REQUIRE  RESISTOR)  ) <’ (RESISTOR  ’Pll>) 
(STRST  (CET-POUER-SUPPLY  ’PI)  ’SUP  <> 

(\  ()  (BCQUIRE  VOLTRCE-SOURCE)  ) <MVS  ’P|)>) 
(STflsr  (Bjt-fihder  ’pd  ’SUp  <> 

(\  () 

(/sEINO 
(\  (Q) 

(EXISTS  (CSI 

(BNO  (COnPONENTS  ’01  ’CS) 

(ELT  ’0  ’CS) 

(HHIH-OEV-TYPE  ’Q  8JD)  )))  ) 

.• (TRANSISTOR  ’PII>) 

(STflSr  (UIRER-1  ’PI)  ’SUP 

.'(RESISTOR  ’PI)  '(TRANSISTOR  ’PI)> 

(\  (R  0)  (TRniNS-CONMECT  (#2  ’R)  (COL  ’0))  ) 

.>) 

(STASX  (UIRER-2  ’PI)  ’SUP 
.' (RESISTOR  ’PI)  ’ (VS  ’Pl)> 

(\  (R  VS)  (TRHINS-CONNECT  (fl  ’R)  (P2  ’VS)i  ) 
<>) 


(REDUCE  .(CET-RESISTOR  ’PI)  (HIRER-1  ’PI)> 

(CONVERT  PORT-1  ’P|)l 
(-/>  A (./>  '(TRANSISTOR  ’PI)  ’Q) 

(-/>  A (/tPLAN-INSTANCE  ’BIAS-PI 

(GENERAL -BIAS-PLAN  ’0)  ’SUP-BIAS) 
(REOUCE  .(CET-POUER-SUPPLY  ’PI) 
(HIRER-2  ’PI)> 

(CB-BIRSER  ’BIAS-PI)  mill 


(Ocrm.A  sPfc-cf-oiR-voL 

ISPCC-SCMEHA  (CE-OIR-VOL -COUPLE  ’01  ’PRT2  ’02) 

(GENERAL -COUPLING-PLAN  ’D1  (OUTPORT  ’Oil 
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2AB 


’PRT2  ’02>)> 


(DtrnLR  PORT-CONVIRT 

(-/>  C (PRO  U PORT  ’PRn 

(./*  ■ (PORT-lFPniNPLS  ’PRI)  <’TRniMl  >TRt11N2>) 

(./.  • (NODE -IFPniNflLS  ’IRniNl)  >TS)) 

I/!  TO-DO  ’TP5I  (PORT-CONVERT  trot  CURRENT  VOLTPCE)  <> 
(CONE  1C  .RESISTONCE. 

(\  (R) 

< (/iFORt 

(OEV-IN-jERT  ’R  ’TRfllNl 

(#1  TR)  7TS  (#2  7R)  <>) 

(\  O 

»(RELneFL-PORT  ’PRT  I-PORT  V-PORT) 
(CONSTRHIN  <•(!  (#1  TR))  (I  TTRt1INl)> 

(\  (IR  IT) 

(/>/>  (RBS  7IR) 

(BBS  ’IT))  ))>  ))>  ))))) 


<OC ffH.»  RClflBEL 

t/iHOD  nPNIP  ’Tsr  (RELBBEL-PORT  ’PRT  ’OID  ’NEU) 
<•(■>010  ■>PRT)>  <’(’NEU  ’PRT)>1) 


ro£rm.fl  pco-nooe  inot  (peusrble  node  mi 

(OEFNLR  PRin-NOOE  IPR  |ni  T I VE-DEV-TVPE  NOOEl  CENERBt-OP*) 


(DETFTLR  2-TERniNOL-OEFN 

l-/>  fi  (DEV-TYPE  ’»  2-IER(1INRL) 

(/:P»T  2 TEPnlNRl  PT T (’X) 

(TERNINBl -NROES  ’X  «#1  #2>) 

(CONSTRPINT  <>(I  1/1  ’X))  '(I  (#2  ’X))> 

(\  (II  12)  (•  (♦  ’ll  ’12)  ()  )) 

(CONSTRBINI  <>(V  ’X)  '(V  (#1  ’X))  ’(V  (/2  ’X))> 
I\  (V  VI  V2) 

I.  ’V  (-  ’VI  ’V2))  DM 


CENERPE-OPt) 


(OEFniR  PRIIT-RESIS  IPRiniTIVE  OEV  TYPE  RESISTOR!) 

(OEEIttR  RESISTOR-OEFN 

l-/>  P (OEV-TYPE  ’X  RESISTOR) 
t/iPET  RESISTOR-PT  T(’X) 

(OEV-TYPE  ’X  2-TERniNPl) 
(CONTROl  ’X  R REBLS  l.»> 
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(CONSTRBINI  <•  (R  n»> 

iLnnBOfl  (Rl  (/>•  ’R  (.1)  )) 

(CONSTRBINT  <’(R  n)  ’(V  (#1  n>) 

• (V  (#2  ’«))  • (1  (#1  ^«))> 
(LRIROn  (R  VI  V2  ID 

(.  (♦  Ml  ’R)  (-  ’VI  ’vzn  mi 

CENERnL-OP»> 

(OEEIILfl  RCQ-RESISTOR  (NOT  (REUSRBIE  RESISTORM) 


(OEEflLB  PRII1-OPEN  IPR IHI T I VE -OEV-TYPE  OPEN)) 


(OEEhlh  open-oefn 

l-/>  n (DEV-TYPE  ’X  OPEN) 

(RND  (OEV-TYPE  ’X  2-TERniNRU 

(CONSTRBINT  <’ (I  (#1  ’X))> 

(LBI1BOB  (I)  (.  M «1 
(CONSTRBINT  <• (I  (#2  ’X))> 

(LBNBDB  (I)  (.  ’I  t) 


CENERBL-DP») 


)) 

mi 


(OErnCfl  PRin-SHORT  IPRiniTIVE-OEV-TYPE  SHORT)) 

(DETnLR  ST(ORT-OEEN 

l-/>  R (OEV-TYPE  ’X  SHORT) 

(RNO  (OEV-TYPE  ’X  2-TERri|MRU  ^ 

(CONSTRAINT  <MV  (#l  ’X))  MV  (#2  ’X))> 

(LBHBOR  (VI  V2)  (•  ’VI  ’V2)  DM 

CENERBl-OPt) 


(OEFNIR  PRin-CBP  (PRinniVE -OEV-TYPE  CRPRCITORI) 

(OEFNIR  RCQ-CRP  INOT  (REUSRBIE  CBPRCITORMI 

(OEFniR  CAP-DEFN 

l-/>  R (OEV-TYPE  “X  CRPRCITORI 
(/iPtT  CRP-P)  T (’X) 

(OEV- TYPE  ’X  2-TERniNflll 
(CONTROL  ’X  C RERI  S 1.21 
(CONSTRBINT  <MC  ’Xl> 

(ERnBOR  (Cl  (/>•  ’C  (.(I  II 
(N  (OC)  MOEV-TYPE  ’X  CRPRCITORI) 

(T  (DC)  (DEV-IYPE  ’X  OPEN)) 

(N  (SSS  ’SI  MOEV-TYPE  ’X  CRPRCITORI) 

(T  (SSS  ’SI  (RNO  (DEV-TYPE  ’X  RESISTORI 
(./.  ’ (R  ’X) 

(//  1.1  (•  (C  ’XI  ’SI)))) 
(N  (HICM-FREQ)  (DEV-TYPE  ’X  CRPRCITORI) 

(I  (NICH-FREOI  (OEV-TYPE  ’X  SHORT)))) 


a 


CENERRl-OPtl 
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j 

k 

t 

; 

i 


lOEFULB  PRin-INOUC  IPRPimvF -OtV-ryPf  INOOCTORJ) 

(DErniB  INOUC-DEFN 

(-/>  n (OEV-TVPf  INDUCTOR) 

(/iPTT  INDUC-PIT  (7*) 

(DEV-TYPE  ’«  2-TERniNRL) 

(CONTROL  ’*  L RERLS  1.51 
(CONSTRRINT  <• (L  ’X)> 

(LROeOR  (L)  (/>.  TC  0.8)  )) 

(N  (DC)  ’(DEV-IYPE  ’X  INDUCTDR)) 

(T  (DC)  (DEV-TYPE  ’X  SHORT)) 

(N  (SSS  ’S)  '(DEV-TYPE  ’X  INDUCTOR)) 

(T  (SSS  ■’S)  (RNO  (DEV-TYPE  ’X  RESISTOR) 
(./>  ■ (R  YX) 

(•  (I  ’X)  ’$)))) 

(N  (HICH-FREQ)  (DEV-TYPE  ’X  INDUCTOR)) 

(T  (HICH-EREQ)  (DEV-TYPE  ’X  SHORT)))! 

CENERRL-DPfi 


(OEFflLR  COHP-xrnR  (COnPOSITE  OEV-TYPE  TRRNSEORHERI  ) 

(OEFniB  XFHR-DEFN 

l-/>  B (OEV-TYPE  ’X  TRONSFOROER) 

{/;P)T  XFHR-PYT  (’X) 


(Tf PrtINRL -NOnCS  ’X  <<11  #12 

fRl  IR2>) 

(CONTROL  ’X 

TURNS-RBTIO  REBLS  1) 

(CONSTRRINT 

<’  (TURNS-RRTIO 

’X)> 

(\  (N)  (/>  «)  )) 

(CONSTRRINT 

■r'  n (A  1 ’X)) 

' (I  (#12  ’X))> 

(\  (11  12)  <>  ( 

♦ ’ll  ’12)  0) 

>) 

(CONSTRAINT 

( I (#R1  n) ) 

’ (1  (#R2  ’X))> 

(\  m 14)  r>  ( 

♦ ’13  ’U)  0) 

)) 

(CONSTRRINT 

<•  (V  (A1  7X)) 

’ (V  (#L2  ’X)) 

’ (V  (#R1  ’X) ) 

’ (V  (#R2  ’X)) 

'tr  (#u  ’XU 

•(I  (iPl  ’X))> 

(\  (Vll  V12  VRl  VR2  IL  IR) 

(.  (.  (»  (-  ’VU  ’V12)  ’ID 
(»  (-  ’VRl  ’VR2)  ’IR)) 
0)  ))))) 

I B TRBNSFORrtER  HBY  CONSIST  Of  TUO  INDUCTORS 

(OEFflLB  OERIVfO-XFnR 

I/tTO-00  ’TBS»  (nB»E  TRPNSFOROER)  <’NflnE> 

(/1OO-5U0NET  (BUH  TWO  INDUCTORS)  «XFnR.)I 
CENERBL-DP») 

(OEFNIB  BUn-INOUCTORS-NE  T 

I-/>  n (/iPlBN  IN5TBNCE  ’PI  (BUH  TUO  INDUCTORS)  ’SUP) 

(BND  (STflSr  (CET-INDUC  1 ’PI)  ’SUP  <> 


d 
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(\  ()  (RCQUIRF  INOUCTOH))  <’(Ll  ’P|l>) 

(cn-iHmic-2  'pd  ’Sup  <> 

(\  n (RrOlllPE  INDUCTOR))  <ML2  ’P|)>) 

ISTRS)  (DBPR  'PII  '5UP  «'(L1  ’PI)  ’ (12  ’PI)> 

(\  (111  2)  (CHDBRn 
(\  («) 

mniN-DEV-TYPE  ’X  TPRNSrOPWR)  ))) 

<■  urnR  ■'Pi)>) 

(STRsr  (CflnRBRR  ’PI)  ’SUP 

<•  (H  ’PI)  • (L2  ’PI)  ■ (XFKR  ’PI)> 

(\  (LI  12  XFRR) 

(/!  INFER  • (C0I1P0NENTS  ’NRHE  <’U  n.2>) 

<>)  ) 

<>) 

(/:MRIH  (RBRR  ’PI)  ’SUP))I 

CENERRL-DP*) 


(OEFniR  lOERL-VS  IIOERL  -OEV-TYPE  VOITRCE-SOURCEI ) 

(OEFflLR  REUSRBLE-VS  IREUSRBLE  VOLIRCE-SOURCEI ) 

(OEEFILR  V5-OEFN 

l-/>  fl  (OEV-TYPE  ’X  VOITRCE  SOURCE) 

(RND  (DEV-TYPE  ’X  2-TER(TINRl) 

(CONTROL  V ’X  RERIS  1) 

(CONSTRRINT  <'(V  ’X)  MV  (#1  ’X))  MV  If2  ’X))> 
(\  (V  VI  V2)  (.  ’V  (-  ’VI  ’V2))  )))I) 

(DEFnifl  PRin-BJT  IPRiniTIVE-OEV-TYPE  BJTI) 

(OtrniR  BJT  OEFN 

t-/>  R (OEV-TYPE  ’Q  BJT) 

(/iPXT  BJT-PTT  (’Q) 

(TCRfllNRl-NRIlES  ’0  -BRSE  Ed  I COL>) 

(CONTROL  polarity  ’Q  »*1  -1>  1)  (NPN  VS  PHP 
(CONTROL  BETR  ’Q  (INTERVAL  1(  5M)  1*1 
iBETR  controllable  UP  TO  ORDER  OF  NRCNITUOE 
(CONTROL  RPI  ’0  RFfll S 1.5) 

iIncrerentrl  base  resistance 

(-/>  A (dOOE  ’Q  ’(1) 

(STASr  (BIASER  ’Q  ’ll)  (DEEP  FREEZE  ’ll)  <> 

(V  ()  (BIAS  ’Q  ’ll)  ) <>)) 

<-/>  A (HOOE  ’0  ACTIVE) 

(AND 

(CONSTRRINT  <MI  (BASE  ’01) 

MI  (COl  ’0)1  MBETA  ’0)> 
(LAIIBOA  (IB  1C  BETA) 

(•  ’1C  (•  ’BETA  ’IB))  )) 

(CONSTRAINT  <MI  (COl  ’Ql)  Ml  (EA|  ’Q))> 
(LAABOA  (IC  IE) 
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(.  u Mc  ’IE)  i.e)  )) 
(CONSTRniNT  <•(!  (BBSE  >Q))>  ZtROP) 
(CONSTPBINT  <’(V  (BRSE  ?QI)  ’(V  (Efll  ’Q>) 
MPOLPRITY  >0), 

(CflflBOn  (VB  VE  S) 

I.  I-  ’VB  ’VE)  It  8.6  ’S))  )) 

(INfQ  (V  (BRSE  ’QH  (V  (EHI  ’Qlt 
(POIRRITY  ’Q)) 

(INEQ  (V  (COL  ’0))  (V  (BRSE  ’Q)> 

(POLRRITY  ’Q») 

(INFO  (I  (COL  ’On  8 (POLRRITY  ’Ql) 

(INEQ  (I  (BRSE  ’Q)l  8 (POLRRITY  ’01) 

(INEQ  0 (I  (ERI  ’Ql)  (POLRRITY  ’Q)))) 

(-/>  fl  (HOOT  'Q  cuTom 
(RNO 

(CONSTRRINT  <•(!  (COL  ’Q))>  ZEROP) 
(CONSTRAINT  <MI  (BRSE  ’Q))>  ZEROP) 
(CONSTRAINT  <’(I  (Em  ’Q)l,  ZEROP))) 

(-/>  R (HOOE  '0  SATURATED) 

(CONSTRRINT  »MV  (COL  ’Q) ) ’(V  (ETTl  ’Q)) 
•(POLRRITY  ’Q)> 

(I RUBOR  (VC  VE  S) 

(.  ’VC  (•  ’VE  (//  (•  8.6  ’S)  2.811)  ))) 

(N  (INC)  ’(CONSTRAINT  <’(V  (BRSE  ’Q))  ’(V  (ETII  ’Q)l 
' (POLARITY  ’Q)> 

(lAtIBOA  (VB  VE  S) 

(.  (-  ’VB  ’VE)  (*  8.6  ’S))  ))) 

(T  (INC)  (CONSTRRINT  <’(V  (BRSE  ’Ql)  ’(V  (ENI  ’Ql) 

'(I  (BRSE  ’Q))  '(RPI  ’Q)  > 

(\  (VB  VE  IB  R) 

(.  (-  ’VB  ’VE)  (•  ’IB  ’R))  ))) 


)l 

GENERAL -0P») 


(OEEHLR  INEQ-l 

(-/>  R (JNEQ  ’»  ’Y  ’S) 

(RNO  (-/>  C (/>  ’S  8)  (/>  ’X  ’Y)) 

(-/>  C (/<  ’S  0)  (/<  ’X  ’Y)))J) 

(COnPOSITE  DEVICES 

(OEEHLR  SIC-TRRNSEP-CIORIR-IIUNDI 

I-/>  R (OEV-TVPE  ’X  SIC-TRRNSER) 

(PORTS  ’X  .(INPORT  ’XI  (OUTPORT  ’Xl>)  )) 


(OEEflLR  NOOES-OECL-DEEN 

t-/>  R (NODES  ’DEV  ’NOOE-TUPI 

l-/>  C (ELT  ’N  ’NODE-TUP)  OTRIN  OEV-TYPE  ’N  NODE))) 
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CENERRl-OP*) 


(OEFfttn  PORTS-OECL-OEFH 

(-/>  n (PORTS  ’OEV 
(-/>  C (ELT 


’PORT-TUP) 

’PRT  ’PORT-TUP)  (OfllN-OEV-TTPE  ’PRT  PORT))!) 


(OEFtlLfl  OnP-SIC-TRBNS  tSUB-OEV-TYPE  flOPLIFIER  SIC-TRRNSER) ) 


(DEFOLR  CE -BASIC  IBflSIC-OEV-TYPE  CE!) 

(OEFniB  CE-nnP  ISUB-OEV-TYPE  CE  RnPUFIERI) 

(OEFnifi  nOST-CEN-CE  (nOST-CENERRL-SPEC  CE  CEMERRL-CEl) 

(DEFflLfi  CE-OEFN 

[-/>  R (OEV-TYPE  ’CE  CENERRl-CE) 

(/iPFT  CE-PTT  (’CE) 

(COMPONFNTS  ’CE  <(Q  ’CE)>) 

(NODES  ’CE  <(BN0DE  ’CE)  (ENOOE  ’CE)  (CNOOE  ’CE)>) 

(OEV-TYPE  (Q  ’CE)  BJT) 

(dOOE  (Q  ’CE)  RCTIVEI 

(/iSUBTBS)  (BIRSER  (0  ’CE)  RCTIVE)  (OEEP-FREEZE  ’CE)) 
(/iTO-DO  (BIRSER  (Q  ’CE)  ACTIVE)  ’R  <> 

(/lOO-SUBNET 

(TYPICAl-BJT-ONE-STRCE-BIRS  (Q  ’CE))  <>)) 


(./>  ’ (NOOE-TERNINRLS  (BNODE  ’CEI)  <(BRSE  (Q  ’CE))>) 
(./>  • (NOOE-TERBINRLS  (ENOOE  ’CE))  <(Eni  (Q  ’CE))>) 
(./>  • (NOOE-TERfllNAlS  (CNOOE  ’CEI)  <(COl  (Q  ’CE)I>) 

i 

(l-PORT  (INPORT  ’CE)) 

^ (PORT-TERNINALS  (INPORT  ’CEI 

.(BNODE  ’CE)  (ENOOE  ’CE)>) 

(l-PORT  (OUTPORT  ’CE ) I 

I 

(PORT-TERniNRLS  (OUTPORT  ’CE) 

.(CNOOE  ’CE)  (ENOOE  ’CE)>) 

! ” 

} CENERRl-OP*) 


(DEFNIR  OEFRUIT-CE  IDEFRUl  T-SPEC  CE  lYPICRl-CEl) 

(OEFRIR  OERIVRTION-TYP-CE  (OERIVEO  TYPICRl-CE  CENERRI-CEI) 

(OEFTH-R  TYPICRl -CE-OEFN 

l/iRNTEC  (NOT  (OEV-TYPE  ’TYP-CE  TYPICRL-CEI) 

(/iPFT  TYPICRl -CE-PFT  (’TYP-CEI 
(OEV-TYPE  ’TYP-CE  CEI 

(CONPONENTS  ’TYP-CE  .(0  ’TYP-CE)  (Rl  ’TYP-CE) 


. • 
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<R2  ’TYP-CE)  (PE  >TYP-CE) 

(PI  nrp-c£)>) 

(tIBIN-DEV-TYPC  (Q  YTYP-CE)  BJT) 

(I100E  (0  ’TYP-CE)  RCTIVE) 

(tIBIN-DEV-TYPE  (PI  ’TYP-CE)  PESISTOP) 
(nOIN-OEV-TYPE  (R2  ’TYP-CE)  RESISTOR) 
IfiniN-DEV-TYPE  (PE  ’TYP-CE)  RESISTOR) 
(HBIN-OEV-TYPE  (PL  ’TYP-CE)  RESISTOR) 

(NOOES  ’TYP-CE  <(BNOOE  ’TYP-CE)  (CNOOE  ’TYP-CE) 
(ENOOE  ’TYF-CE)  (OMD  ’TYP-CE) 
(PNOOE  ’TYP-CE) >) 

(./>  ' (NOOE-TEPfllNPLS  (BNOOE  ’TYP-CE)) 

<(BP3E  (Q  ’TYP-CE))  (#2  (PI  ’TYP-CE)) 

(#1  (R2  ’TYP-CE))>) 

(./>  ’ (NOOE-YERdlKPLS  (ENOOE  ’TYP-CE)) 

.(ft1|  IQ  ’TYP-CE))  (PI  IRE  ’TYP-CE))>) 

(-/>  • (NODE -TCRniNRLS  (CNOOE  ’TYP-CE)) 

<(COL  (Q  ’TYP-CE))  (#2  (PL  ’TYP-CE))>) 

(./>  • (NODE -TEPniNOLS  (PNOOE  ’TYP-CE') 

<(/l  (Rl  ’TyP-CE))  (#1  (PI  ’TYP-CE))>) 

(./>  ' (NOOE-TERniN«LS  (CNO  ’TYP-CE)) 

<(#2  (R2  ’TYP-CE))  (#2  (PE  ’TYP-CE))>) 


|FP02EN  TflSrS 

(/iPlflN- INSTONCE  (FROc'EN-BIBS-PLRN  ’TYP-CE) 

(TYPICRI  BJT-ONE-STPCE-BlflS  (0  ’TYP-CE)) 

(BIflSER  (Q  ’TYP-CE)  BCTIVE)) 

(/iPEOUCEO  (BIflSER  (Q  ’TYP-CE)  RCTIIrt)) 

(FUNCTION  (PI  ’TYP-CE)  (BVO  (FR02EN-BIPS-PIRH  ’TYP-CE))) 
(FUNCTION  (P2  ’TyP-CE)  (BVO  (FPOZEN-BIPS-PIRN  ’TYP-CE))) 
(FUNCTION  (RE  ’TYP-CE) 

(RESIS-CETTEP  (FROZEN-B IRS-PIPN  ’TYP-CE))) 


(STRSF  (PORT-CVT  ’TYP-CE)  (OEEP-FREEZE  ’TYP-CE)  <> 
(\  ()  (CONVEPI  PORT  (OUTPOPT  ’TYP-CE) 

CURRENT  VOITRCE)  ) 

<>) 

(FUNCTION  (PL  ’TYP-CE)  (PORT-CVT  ’TYP-CE)) 

(EXPRNSION-OBL  ’TYP-CE  (FIX  MV  (PNOOE  ’TYP-CE)))) 
(/iSUBTOSr  (OBI  ’TYP  CE  (FIX  MV  (PNOOE  ’TYP-CE)))) 
(BIPSER  (0  ’TYP-CE)  fiCTIVE)) 

(CONSTPRINT  .MPOlRRITY  (0  ’TYP-CE)) 

MSICN  (V  (PNOOE  ’TYP-CE)))> 

• ) 

(CONTROL  V-CRIN  ’TYP-CE  (INTERVAL  -58  SI)  2) 
(CONSTPRINT  .MV-GflIN  ’TYP-CE)  MR  (PL  ’TYP-CE)) 
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MR  (Rt  nvP-CEM> 

(IBUSDR  (RV  RL  RE)  (•  ^RV  (//  ^Rl  »RE)»  n 
M 

CEWRBl  -0P«) 


(OEFm.n  BRSIC-VO  IBRSIC  DEV-TYPE  VOl ) 

(OEEm.R  VD-OEEN 

(-/>  fl  (DEV-TYPE  ’VO  V0» 

(/iPTT  VO-PTT  (’VOl 

(COMPONENTS  ’VO  <(R1  ’VO)  (R2  ’V0)>) 

(NODES  ’VO  «(T0P  ’VO)  (RIO  ’VO)  (BOT  ’VO)>) 

(KRIN-OEV-TYPE  (R1  ’VO)  RESISTOR) 

(MRIN-DEV-TYPE  (R2  ’VO)  RESISTOR) 

(./>  MNODE-TERniNRLS  (TOP  ’VO))  <(#1  (Ri  ’VO))>) 
(./>  MNOOE-TERMINRLS  (RIO  ’VO)l 
.(#2  (Rl  ’VO))  (#l  (R2  ’VO))>) 

(./>  MNOOE-TERRINRLS  (BOT  ’VO)) 

<(/2  (R2  ’VO))>) 

(OEV-TERRINRLS  ’VO 

<(TOP  ’VO)  (RID  ’VO)  (BOT  ’VO)>) 


iFROCEN  TflSES 

(EXPRNSION-OBl  ’VO  (FIX  MV  (TOP  ’VO)))) 
(EXPRNSION-OBl  ’VO  (FIX  MV  (BOT  ’VD)I)I 


(CONSTRRINT  <MV  (TOP  ’VO))  MV  (BOT  ’VO)) 
■ (V  (RIO  ’VO)) 

’ (R  (Rl  ’VO))  ’ (R  (R2  ’VO))> 
(\  (VI  V2  V Rl  R2) 

(.  ’V  (//  (♦  I*  ’R2  ’VI)  (•  ’Rl  ’V2)) 
(♦  ’Rl  >R2)))  )) 


)) 


(CONSTRRINT  <MI  (RIO-NOOE  ’VO)) 

Ml  (#2  (Rl  ’VDII)> 

(\  (I  III  (/</<  (RBS  ’I)  (RBS  ’ll))  I) 

(CONSTRAINT  .Ml  (RIO-NOOE  ’VO)) 

MI  (/I  (R2  ’VO)))> 

(\  (I  121  (/./<  (RBS  ’I)  (RBS  ’121)  >1 


GENERAL -OP*) 


lOCFRlR  RCO-VD  INOT  (REUSABLE  VOID 
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)RS  UITM  it,  THfRE  IS  RN  RRSTRflCT  E :P  UHICH  IS  R CURRENT  flnPLIEIER 
(DEEniR  BRSIC-ECP  IBRSIC-DEV-IYPE  ECPI ) 

• OEFniR  ECP-IS-RnP  ISUB-OEV-TYPE  ECP  RIIPUEIERII 
(OEEfILR  nOST-CENERRL-ECP  inOST-CENERRL-SPEC  ECP  CEHERRL-ECPI I 
(OEFflLR  ECP-DEEN 

U/>  R (DEV-TYPE  ’ECP  CENERPL-ECP) 

(/iPTT  ECP-PTT  (’ECP) 

(CODPONENTS  ’ECP  -(01  ’ECP)  (02  ’ECP)>) 

(MOOES  ’ECP  <(tNOOE  ’ECP) 

(6N00EI  ’ECP)  (6N00E2  ’ECP) 

(CNOOEl  ’ECP)  (CN0DE2  ’ECPI>) 

(flRIN-OEV-TYPE  (01  ’ECP)  BJT) 

(MOOE  (01  ’ECP)  RCTIVE) 

(KRIN-DEV-TYPE  (02  ’ECP)  BJT) 

(RODE  (02  ’ECP)  ACTIVE) 

(./>  • (NOOE-TERtllNRLS  (ENOOE  ’ECP)) 

<(En|  (01  ’ECP))  (ERl  (02  ’ECP))>) 

(./>  • (NOOE-TERniNRLS  (BNOOEl  ’ECP)) 

<(BRSE  (Ql  ’ECP))>) 

(./>  ■ (NODE-TERniNRLS  (BM00E2  ’ECP)) 

<(BR5E  (02  ’ECP))>) 

(./>  • (NOOE-TEPniNRLS  (CNOOEl  ’ECP)) 

-(COl  (01  ’ECP))>) 

(./>  • (NOOE-TERrilMRLS  (CN00E2  ’ECP)) 

<(COL  (02  ’CCP))>) 

(PORTS  ’ECP  .OUTPORT-1  0UTP0RT-2>) 

(V-PORT  (IMPORT  ’ECP)) 

(PORT-TERRINRLS  (INPORI  ’ECP) 

‘ .(BNOOEl  ’ECP)  (BN0DE2  ’ECP)>) 

I 

I (I-PORT  (OUTPORT-1  ’ECP)) 

(PORT-IERRINRI  S (OUTPORT-1  ’ECP) 

.(CNOOEl  ’ECP)  (ENOOE  ’ECP)>) 

(I-PORT  (OUlPORI-2  ’ECP)) 

(PORT-TERRINRl S (OUTPORI-2  ’ECP) 

.(CN00E2  ’ECP)  .ENOOE  ’ECP)>) 

(/tSUBTRSr  (BIRSER  (01  ’ECP)  RCTIVE) 

(DEEP  TREE2E  ’ECP)) 

I (/iSUBTflSr  (BIRSER  (02  ’ECP)  RCTIVE) 

< (DEEP  TREE2E  ’ECPI) 

(EXPRNSION-OBl  ’ECP  (FIX  ’(I  (ENOOE  ’ECPI)))))) 


(OCFncfl  OEFRULT-ECP  (OEFflUl T-SPEC  ECP  ECP-OC-RRPI ) 


(OtFflLB  OtRIVtD-tCP-OC-BnP  lOtPIVtO  tCP-OC  nnP  ECPl) 

(OEFm.fl  ECP-OC-BnP-OfFN 

(/.ARTEC  (ROT  (OEV-TVPE  TTTP-ECP  ECP-OC-BRP)) 

(/.PtT  ECP  OC-RHP  PH  OTYP-ECP) 

(CORPONENIS  MYP-ECP 

<(OI  ’TYP-ECP)  (02  TTYP-ECP> 

(PL  ’TYP-ECP)  (RE  ’TYP-ECP)>) 

(OEV-TVPE  (RL  ’TYP-ECP)  RESISTOR) 

(PEV-TyPE  (RE  ’TYP-ECP)  RESISTOR) 

(DEV-TYPE  IQI  ’TYP-ECP)  BJT) 

(OEV-TYPE  (02  ’TYP-ECP)  BJT) 

(nOOE  (01  ’TYP-ECP)  ACTIVE) 

(RODE  (02  ’TYP-ECP)  ACTIVE) 

(Roots  ’TYP-ECP 

<(EN00t  ’TYP-ECP)  (lOHNOOE  ’TYP-ECP) 

(HICHNOOE  ’TYP-ECP) 

(C2N00E  ’TYP-ECP)  (BIROOE  ’TYP-ECP) 

(B2N00E  ’TYP-ECP)>) 

(./>  • (ROOt-TERniNALS  (ERODE  ’TYP-ECP)) 

<(ERI  (01  ’TYP-ECP))  (EHI  (02  ’TYP-ECP)) 

(/I  (RE  ’TYP-tCP))>) 

(./>  • (NODE-TERniNAlS  (LOUROOE  ’TYP-ECP)) 

<(#2  (RE  ’TYP-ECP))>) 

(./>  • (NODE-IERniNRlS  (HICHRODE  ’TYP-ECP)) 

<(COL  (01  ’TYP-ECP))  (#1  (RL  ’TYP-ECP))>) 

(./>  ■ (NOOE-TEPdlNAlS  (C2H00E  ’TYP-ECP)) 

<(COC  (02  ’TYP-ECP))  (#2  (RL  ’TYP-ECP))>) 

(./>  • (NOOt-TERnlNRLS  (BIMOOE  ’TYP-ECP)) 

<(BRSE  (01  ’TYP-ECP)  )>) 

(./>  • (ROOE-TERniNALS  (B2R00E  ’TYP-ECP)) 

<(BASE  (02  ’TYP-ECP) )>) 

•THESE  ARE  UAYS  OF  DOING  TAS) S IN  ABSTRACT  ECP... 

(EFPANSIOR-OBL  ’TYP-ECP 

(F|«  MV  (LOUROOE  ’TYP-ECP)))) 
(EXPANSION-OBI  ’TYP-ECP 

(FIX  MV  (HICHNOOE  ’TYP-ECPMM 

(REDUCE  <(OBl  ’TYP-ECP 

(FIX  MV  (LOUROOE  ’TYP-ECP) ))) > 

(OBI  (SOUL  ’TYP-ECP) 

(FIX  MI  (ENOOE  (SOUL  ’TYP-ECP) ))) I ) 

(REDUCE  »(OBL  ’TYP-ECP 

(FIX  MV  (HICHNOOE  ’TYP-ECP) I )) > 
(BIRSER  (Ql  (SOUL  ’TYP-ECP))  ACTIVE)) 
(REDUCE  «(OBl  ’TYP-ECP 

(FIX  MV  (HICHNOOE  ’TYP-ECP) I ) I > 
(BIASER  (02  (SOUL  ’TYP-ECP))  ACTIVE)) 


(STRSr  (CVT-PORT  ’ECP)  (0CEP-FREE2E  ’TYP-ECP) 
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• > (\  ()  (PORI  CONVtm  (OUTPORT  ’TyP-tCP) 
CURRENT  VOLTRCO  ) <>) 
(FUNCTION  (RL  nyP-lCP»  (CVT-PORT  TECPH 

(FUNCTION  (Rf  ?TyP-tCP) 

(OBL  (SOUL  nyP-ECPI 

(FI*  Ml  (ENOOE  ’ECP)»))» 

(CONSTRAINT  <MI  (RE  TTyP-ECP))> 

(\  (I)  (•  T|  g.et2l  II 
(CONSTRAINT  <MI  (COL  (Ql  ’TyP-ECPIll 
Ml  (COL  (02  ’TyP-ECPIII> 

• nil 


(OEFula  rc-oev-type 

U/>  fl  (OEV-TYPE  'RC  RC-FILTERI 
(/iPFT  RC-PIT  (-RCI 

(OEV-TYPE  ’RC  SIC-TRANSERI 
(COnPONENTS  ’RC  <(R1  ’RCI  (Cl  ’RCI>I 
(N';OES  ’RC  .(NOOEl  ’RCI  (N00E2  ’RCI  (NODES  ’RCI>I 
i./>  MNOOE-TERniNALS  (NOOEl  ’RCIl  <(#1  (R1  ’RCII>I 
(./>  MNOOE-TERTTINAIS  (N0DE2  ’RCIl 
<(#2  (R1  ’RCIl  (#l  (Cl  ’RC11>1 
(./>  MNOOE-TERniNALS  (NODES  ’RCIl  <(#2  (Cl  ’RCI1>I 

(V-PORT  (IMPORT  ’RCIl 

(PORT-TERHINALS  (import  ’RCI  <(N00E1  ’RCI  (MOOES  ’RCI>1 
(V-PORT  (OUTPORT  ’RCIl 

(PORI-TEROINALS  (OUTPORT  ’RCI  « (NODE 2 ’RCI  (MOOES  ’RCI>I 

(CONTROL  CUTOFF-FREQ  ’RC  POS-RERLS  II 
(CONTROL  (M  ’SI  ’RC  COnPLE*  1.21 

(CONSTRAINT  »MCUT0FF-FREQ  ’RCI 

MR  (Rl  ’RCIl  MC  (Cl  ’RCH> 

(V  (F  R Cl  (.  ’F  (//  1 (•  ’R  ’em  II 

(CONSTRAINT  < M (H  ’SI  ’RCI  MR  (Rl  ’RCIl  MC  (Cl  ’RCII> 

(V  (H  R Cl  (•  ’H  (//  1 (•  1 (•  ’R  ’C  ’Sllll  II 

111 
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Appendix  4 --  Details  or  STP  for  Theorem  Provers 

The  main  requirement  for  an  information-retrieval  theorem  prnver  i that 
it  halt.  This  is  hard  because  it  must  return  as  many  answers  as  pn'isihle.  If 
the  theorem  prover  were  the  top  level,  as  is  usually  the  case,  ue  could  just 
let  It  run  until  we  ran  out  of  money  or  patience,  but  the  problem  solver  above 
it  needs  its  answers  in  a finite  time.  STP  has  been  written  with  ttiis 
emphasis  In  mind;  In  its  design,  I have  sacrificed  "completeness"  to  this 
"finiteness"  requirement. 

STP  is  organizer!  as  a backward-chaining  PLANNER-1  ike  system.  (Moore,  n75) 
Given  a goal,  it  finris  implications  to  back  through.  For  example,  iiitli  tlm 
goal  "Refute  (NOT  (P  TK)]."  it  might  back  through  [-/>  C (AND  (Q  ’Ml  (R  ’Ml) 

(P  ?X)],  which  is  Internally  stored  as  the  disjunction  l/tCONSEQ  (P  ’X)  (NOT 
(AND  (Q  ’XI  (R  ?X))I1).  The  reason  Implications  are  internally  rl  i s junc t i ons 
is  that  STP  wants  to  retrieve  /:ANTECs  in  the  same  fetch  as  /:C0NSEQs.  so  it 
must  put  the  index  pattern  in  the  same  place.  It  is  for  this  reason  that 
atomic  riata  are  stored  as  (/rCONSEQ  |pat|  FALSE). 

This  backward  chaining  creates  a conjunction  of  subgoals,  each  of  uhicti  Is 
treated  similarly  to  the  way  the  top-level  one  was.  The  ottier  suirgoa  I s ar  r. 
held  in  abeyance  while  the  chosen  one  Is  worked  on.  This  is  called 
"splitting"  for  reasons  I will  explain  below.  The  chosen  subgoal  can  sfirout 
new  subgoals,  so  the  conjunction  grows. 

Uhen  a subgoat  Is  reduced  to  FALSE,  the  resulting  answer  substitution  is 
applied  to  the  remaining  conjuncts  before  they  are  split.  Uhen  there  aren't 
any  more,  the  substitution  is  the  final  result.  I will  say  more  about  "amuer 
substitutions"  below. 

Backtracking  is  necessary  because  there  may  be  more  than  one  split,  ami 
because  there  may  be  more  than  one  answer  to  try  on  remaining  conjuncts. 
Backtracking  is  implemented  by  saving  the  theorem-proven  state  when  surh  a 
choice  arises;  and  restoring  such  states  when  branches  run  out  of  choices,  and 
after  each  top-level  answer  has  been  found. 

To  limit  backtracking,  failures  are  not  allowed  to  cause  backtrarkmri  to 
an  irrelevant  choice  point.  Splits,  when  generated  or  augmented,  are 
partitionerl  into  "split  groups."  each  member  of  which  is  a conjunction  which 
shares  no  free  variables  with  the  others.  (Ernst,  1973,  Moore,  1975)  For 
example,  if  (-/■»  C (AND  IP  ’x)  (Q  ?y) ) (R  ?x  ?y)l,  the  goal  (NOT  IR  ’u  ’v)) 
gives  rise  to  two  independent  subgoals  (NOT  IP  ?u)  1 and  (NOT  (0  ’vl).  All  tlie 
answers  are  found  to  each,  and  the  result  is  the  "Cartesian  product"  of  ttie 
ansu*-  of  each.  That  is,  if  (P  a)  and  (P  b)  , and  (Q  c)  and  (0  rl)  ar  e 

present,  (R  a c)  , (R  a rl) , (R  b c) , and  (R  b d)  are  deducible. 

A request  to  STP  with  free  variables  is  interpreted  as  a demand  for  values 
of  those  variables  which  refute  the  request.  In  the  example  I just  rpivn,  ttm 
request  (NOT  (R  ?u  ’vl)  is  satisfied  by  four  such  sets.  These  am  callr>d 
answer  substitutions.  They  are  computed  from  the  history  of  the  matcf'rs  from 
the  original  request  to  the  instances  of  (FALSE)  that  are  ultimately  dei  ived. 
For  example,  given  the  reriuest  (NOT  (P  ?x  ?y) ) and  the  axioms  (/:^0N^ffJ  IP  ?ii 
B)  (NOT  (Q  ?u)  ) ) and  (/:C0NSEQ  (NOT  (Q  A))  FALSE),  the  first  backuarri  chain  to 
(NOT  (Q  ?x))  constrains  ?y  to  be  (BI ; the  chain  to  (FALSE)  then  sets  ’x  In 
(A)  . 

This  bookkeeping  is  handled  in  STP  by  use  of  the  Boyer-Moore 
representation  of  clauses.  (Boyer  and  Moore,  1972)  The  idea  is  to  repfi’mnt 
every  clause  as  a pattern  plus  substitution.  The  substitution  is  callnd  ,iri 
environment.  A formula  represented  this  way  is  called  a closure.  Matchiini 
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tuo  closiK-es  rreates  a neu.  more  constrained  environment  uhich  rlesc  r i lif'-.  ttm 
neu  substitution  as  a further  specification  of  the  tuo  old  ones.  In  this  nay, 
each  environment  really  specifies  a binary  tree  of  super-environments  ubifh 
parallel  its  fleductive  history.  Boyer  and  Hoore  explain  hou  a numer  ical 
"environment  id"  nr  envid  can  specify  any  branch  of  this  tree.  Givinq  fun 
envids  specifies  the  node  uhere  the  tuo  branches  meet. 

STP  uses  this  device  to  keep  track  of  ansuers  to  goals.  The  vai  i ah  I e AN5- 
ENVID*  specifies  the  envid  of  the  current  main  goal.  The  variable  flAifJ  MAH* 
specifies  the  sire  of  the  tree  above  the  main  goal’s  environment;  that  is, 
ANS-ENVID*  and  ANS-ENVIO*  + MAIN-nAX«  are  tuo  envids  uhich  unir)uply  '•■pi>c  i f y 
the  environment  of  the  main  goal.  The  function  ENV-C0LLAP5E  takes  the 
environment  of  a terminal  [EALSE]  and  these  tuo  numbers  and  produces  an 
environment  uith  all  the  discovered  constraints  recorded.  This  merbanism 
makes  unnecessary  the  "ansuer -pred i cate"  construct  of  (Green,  13GT).. 

Of  course,  this  mechanism  is  more  spec i a I i zed  than  Green’s,  sinre  it  is 
not  able  to  return  "rli  s junc  1 1 ve"  substitutions.  Thus,  it  uill  not  imrk  if  tlie 
request  [NOT  (P  'i’H))  afipears  uith  (/:C0NSEQ  (P  A)  (P  B)),  even  tho'K|li  theso 
formulas  are  prnvably  inconsistent.  (The  (P  B)  detached  by  the  first 
resolution  matches  the  original  goal.)  It  uon’ t uork  because  there  is  no 
assignment  of  one  value  to  X uhich  refutes  (NOT  (P  ?X)1.  This  is  not  leallq  a 
deficiency  in  doing  information  retrieval,  but  ue  must  be  careful  to  rieter  t 
it.  I uill  say  hou  this  is  rinne  after  a short  digression. 

STP  is  a r e f u t a 1 1 on-fIr  i ven  theorem  prover.  This  means  that  it  rloesn’ t 
just  back  through  implications,  it  also  records  the  formulas  it  is  trying  to 
refute  so  that  they  can  take  part  in  deductions.  Utien  the  prover  retuins.  all 
of  these  effects  must  disappear.  This  is  accom|)  I i shed  by  "pushing"  thr* 
current  data  pool,  doing  recording  formulas  in  it.  and  "popping"  at  the  eivl. 
(HcOermott  and  Sussman.  1373)  This  is  done  for  every  subgoal  as  ue  I I . 

Noil  the  machinery  can  allou  several  kinds  of  interactions  lietiienn  gnals. 
The  kind  1 mentionerl  tuo  paiaqrafihs  ago  is  called  "befuddlement . " T ti  i . Is  utien 
tuo  matching  suhgoa  I s specify  conflicting  substitutions.  This  is  tiaivlleil  iiy  .a 
program  ( TP-ST  A TUS  - PECriNC  | ( f,  I , uhich  forces  agreement  betueen  tuo  conflirfinq 
lines  of  deduction;  it  insists  that  just  one  ANS-ENVID*  be  passed  alnny. 

Another  kind  of  Interaction  is  subsumption.  If  a neu  goal  is  sule.ui'ed  iiy 
a fact  not  in  the  pushed  rlata  pool,  it  is  abandoned.  For  example,  even  if 
there  are  axioms  for  proving  (P  ?X)  , there  is  no  point  in  trying  to  p nve  (f’ 

A]  (that  is,  refute  (NOT  (P  All),  if  (NflT  (P  A)]  is  in  the  data  basn.  If  you 
succeerted  in  deriving  sucti  a proof.  It  uould  be  of  little  value,  since  it 
would  just  prove  the  inconsistency  of  the  data  base  uith  regard  to  tfiis 
ques  t i on. 

Dore  interesting  is  t)ie  case  uhere  the  subsumer  is  another  goal.  This 
case  must  be  nnticeci,  since  the  subsumer  may  be  a super-goal  of  the  cunent 
one,  and  therefore  an  infinite  recursion  may  be  Impending.  I any  ra're.  there 
is  usually  no  point  in  proceeding,  so  STP  abandons  this  goal.  (This  jnits  the 
program  even  further  from  tleductive  completeness.)  However,  there  Is  an 
important  case  in  which  mere  abandonment  is  not  enough.  If  the  super  goal  is 
a main  super-goal  uhich  is  a variant  of  the  current  one,  the  ansuers  to  the 
super-goal  must  be  applied  to  this  one.  For  example,  given  the  axioms 


t/:C0NSEQ  (ABOVE  ?X  ?Y)  (NOT  (ON  ?X  ?Y)M 
l/rCONSEQ  (ABOVE  ?X  ?Z) 

(NOT  (AND  (ABOVE  ?X  ?Y)  (ON  ?Y  ?Z)D) 
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(cf.  (Moorp.  15751),  thp  rp(|i)pst  "Refute  (NOT  (ABOVE  A ?V)1"  uill  ciP'Tto  .1 
sutiqoa  I (NOT  (ABOVE  A ^Yll  uhlch  19  suPsumed  by  it.  The  resultmr)  infiuitr> 
recureion  is  uni  mpor  t ,in  t to  .1  plain  theorem  proven,  hut  important  tn  us.  (lip 
solution  is  to  connect  the  superrjoal  and  suhgoal  in  such  a uay  tli.il  ill 
answers,  past  and  future,  to  the  supergoal  are  translated  into  suhgn.il 
answers.  Thus,  if  the  data  base  contains  (ON  A BJ  , (ON  B C)  , anil  (ON  ( (i)  , 
the  given  request  will  first  generate  V ^ (B) . The  repeate'l  suhf)n.il  mil  im 
noticprl,  and  this  first  ansiier  will  be  used,  causing  the  detachment  of  suliunal 
(NOT  (ON  B "^V)].  Uhen  this  succeeds,  the  answer  V -•  (C)  will  have  been  lounri. 
Now  this  answer  is  used  to  reawaken  the  repeated  subgoal  again,  this  tune 
detactiing  (NOT  (ON  C '^V))  and  given  answer  V ((3).  The  final  goal  (ON  (1  7VJ 
produces  no  new  answers. 

The  ability  to  notice  anri  use  repeated  subgoals  depends  on  the  i a 1 1 u I .i  I i on 
of  answers  to  sutHjoals  as  well  as  the  main  theorem-prover  goal.  This  is 
surprisingly  difficult  to  accomplish  in  conjunction  with  the  split-r|rnup 
sorting  mechanism.  Because  goals  can  be  reorriered.  it  is  not  olivious  uhen  ttip 
last  subgoal  of  a gn.il  has  been  finished.  Every  goal  strucfure  must  s t ni  e a 
stack  of  its  ancestors.  The  program  ANSUERS -RECORD  checks  this  staik  in  sn,.. 
for  each  ancestor,  whettier  there  are  any  outstanding  sibling  tjoals.  If  not, 
an  .answer  for  ttiat  ancestor  may  he  recorded. 

Uh  1 I p working  on  one  split  of  a goal,  STP  does  not  recorri  competinn  splits 
in  thp  dat.i  b.ase.  Ttius,  some  of  the  more  devious  kinds  of  reasoning  d 1 sr  1 is'ierl 
by  R.  Moore  (1575)  are  not  noticed.  This  could  be  changed  without  ton  murh 
trouta I e. 

Other  features: 

[Quality  --  STP  uses  egualities  of  the  form  (-/>  '|x|  |y|l  rnutinelg,  much 
as  a programming  I anguat|p  does.  (Cf.  Bledsoe  and  Tyson.  1575)  The  funrtmn 
EMI  A -CL nSF - ANO -OP  EVAL  creates  a Boyer-Moore  closure,  and  attempts  to  ev.ilu.ate 
subexpress  I one  which  have  been  changed  by  the  new  environment.  Evalu.it  ion  is 
a call  to  STP  with  a request  to  refute  (-/>  ’(new  pat|  ^VAL) . Before  this 
call  is  made,  the  variables  in  the  pattern  are  "marked  universal,"  mninmri 
they  are  not  al  lowed  tn  tie  set  by  the  matching  done  by  STP;  •(•>i  i s turns  nut  to 
be  equivalent  to  the  mai  k 1 ng  done  in  packets.  (McDermott,  1975)  If  it  were  not 
done,  more  than  one  "value"  could  be  derived  for  the  new  pattern. 

This  evaluation  is  done  whenever  a pattern  is  detached.  For  pKample, 
g i ven  the  ax i oms 

(-/>  ’ (F  (G  A) ) 01  (./>  ■ (F  (G  C) ) D) 

(/:C0NSEQ  (P  (G  ’X)  ’Y)  (NOT  (Q  ?X  ?Y))1 
(/tCDNSEf]  (Q  A 7Y)  (NOT  (R  ?YD] 

(R  B1 

and  the  request,  "Refute  (NOT  (P  '^U  (F  ?U))1,"  the  system  detaches  fiist  (fJOT 
(Q  '^X  (F  (G  ^X)))l,  withi)  .•  (G'^Xl.  The  at  tempt  to  evaluate  (F  (G  “^X ) ] f ,1 1 1 9 
because  X would  have  to  be  bound  to  A and/or  C.  The  next  subgoal  is  (NOT  (R 
(F  (G  A ) ) ) 1 , which  is  ev,iluated  to  become  (NOT  (R  B)l,  which  succeeds.  (he 
final  answer  is  U • (B1  . 

The  same  kind  of  substitution  is  done  in  a more  limited  way  when 
equalities  are  to  be  refuted.  For  example,  STP  is  told  to  prove  (FOMAl  I (X) 
(IMPLIES  (EL  T ?X  <A  B C>)  (P  ?X))|  by  asking  it  to  refute  (lilPLIES  (LI  ( X'hJ 
<A  B C>)  (P  X'63)l,  where  X'G5  is  a skolem  form.  It  assumes  (ELT  XiL.5  *A  B 
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C>]  anf)  (NOT  (P  K'FiO)).  Thp  first  subgoal  becomes,  via  the  definition  nf  Pt  T. 
(OR  ('/>  'K'GR  A)  (./-»  'K'KO  R)  (■./>  ’X'GR  CM.  Uhen  this  is  split,  the  first 
sutrgoal  generated  is  ('•/>  ’K'B3  A).  The  only  effect  this  can  have  is  Inj 
substitution,  sn  the  system  finds  all  formulas  that  mention  X*(^3  .anrl  dofs  the 
indicated  replacements.  (There  won’t  be  very  many,  because  X'(^3  is  a new 
skolem  form.)  In  this  case,  the  subgoal  (NOT  (P  A))  will  be  generateri. 

Similar  things  will  happen  in  the  other  two  branches  of  this  split.  To  ruake 
this  work  reguires  a hit  of  mechanism  not  usually  implementerl  in  theorem 
provprs;  the  data-base  machinery  of  (HcDermott,  1375)  must  be  auc|menterl  so 
that  from  any  pattern  one  can  retrieve  all  the  formulas  which  contain  it. 

This  is  done  by  keeping  track  of  all  the  positions  an  atom  appears  in.  anr) 
intersecting  the  index  tiuckets  corresponding  to  atom  positions  comfiatilile  with 
the  pat  t er  n . 

Modality  --  Complications  are  introduced  by  the  use  of  flata  pools  to 
implement  "reference  points."  (Sect.  II.B.2)  Uhen  the  system  has  a goal  of 
the  form  (T  |ref|  |fact|l.  it  attempts  to  "coerce"  the  ref  into  a data  (inol. 

It  then  pushes  this  data  pool  as  it  did  the  calling  one.  and  puts  the  fact 
into  it  for  refutation. 

Data  Dependencies  --  STP  keeps  track  of  the  data  that  support  its 
conclusions.  Its  caller  will  use  these  to  build  data  dependencies  as 
described  in  Sect.  II. D.  The  only  tricky  part  to  this  is  to  make  sure  thp 
data  pools  are  kept  straigtit.  Uhenever  working  on  a (T...1  expression  canons 
a jump  to  a new  pool,  the  supporters  will  be  packaged  up  in  the  form  ILill  1 
I poo  I name  I |fact|).  These  ultimately  end  up  in  this  form  in  the 
dependencies.  (See  Sect.  II. D.) 

life  with  Boyer  and  Moore  J Moore  has  informed  me  (personal 
communication)  that  several  people  have  used  their  representation  for  clauses. 
(1372)  For  the  benefit  of  those  tempted  to  use  it.  I should  repor  t my 
experiences  with  it. 

My  original  motivation  for  wanting  to  represent  formulas  as  closurn.-,  was 
to  preserve  a perspicuous  representation  of  goals  for  interaction  with  advice. 
The  usual  predicate-calculus  theorem  proven  renames  all  the  var  iables  in  two 
formulas  before  unifying  them;  this  is  called  "standardizing  them  apar t . " 

Boyer  and  Moore’s  motivation  was  to  save  storage  by  representing  rlau'es 
incrementally,  as  the  rlifferences  between  input  clauses  and  output  claurer 
deduc  t i ons. 

Neither  of  these  reasons  turned  out  to  be  important,  so  that  tliis  is  a 
classic  examfile  of  ttie  rlangers  of  bottom-up  programming,  or  an  t i c i pa  t i nr; 
problems  that  never  arise  or  are  swamped  by  other  effects.  As  I rliscus'xl  in 
Sect.  VI. B.  my  rieductive  rioals  never  interact  with  advice  anyway:  anti  Rnuei 
anr)  Moore’s  effort  to  save  storage  is  wasted  in  a system,  like  mine,  uh  i t h 
must  index  each  clause  atom  by  atom.  (Actually,  the  system  is  not  guite  th.it 
stupid,  but  I think  any  savings  incurred  are  minute.) 

On  the  other  hand,  the  representation  has  proven  to  tiave  several  vc-i  u 
natural  uses.  The  packet  machinery  of  (McDermott,  1375)  "actualizes" 
f tential  items  by  just  re|)lacing  the  potential  environment  with  tlir'  rnti  ime. 
The  answer  calculation  riescribed  above  is  completely  natural  in  a system  tiiat 
represents  clauses  by  their  deductive  histories.  The  evaluation  mact’inery 
that  trie-  to  evaluate  only  subexpressions  with  newly  instant i ateil  vari.ibles 
Operates  by  traversing  the  expression  to  tie  evaluated,  comparing  vat  i ali  I e 
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values  in  the  old  environment  uith  those  in  the  neii. 

On  balance,  my  conclusion  is  that  these  advantages  do  not  outunigh  H'«' 
disadvantages,  which  are  considerable.  The  principal  one  is  that  t AM  ami  f OR 
are  useless  for  operating  on  closures.  Vou  cannot  take  the  first  slop  into  .a 
closure  without  setting  up  its  environment.  Every  function  ttiat  man  1 1 m I a t r*s 
them  must  tre.at  assicined  variables  as  though  ttiey  were  transparent  (i.e.,  i|n 
steal  gh  t to  their  va  I ues  I ; and  correctly  hanrt  le  envid's  that  rlirert  al'rnlinn 
to  the  proper  par  ts  of  ttie  environment  tree.  Rnyer  and  Hoore  stinii  in  Hir-ir 
paper  that  it  is  easy  to  write  a unification  algorithm  for  clnsuir.s.  indrorl, 
if  is  easy  to  write  any  one  algorithm,  hut  the  fact  that  every  manipul  i ' i nn 
has  to  take  the  samr>  tortious  cases  into  account  ,9  somethinr)  1 'hrin'  ' 'ni 
1 so  I vert  this  protrlem  to  Some  der|ree  hy  writing  a set  of  funr  lions  (with  n.imr-s 
like  FflAP  and  FMACKI  which  (analogously  to  LIRF''g  tlAP  functions)  map 
operations  over  Rnunr  flonr  r>  tl,at.a  structures.  Rut  these  turn  tiriris  fravn  In  h 1 nr) 

3)'ec  i a I varlalilos  .and  usn  tlAf  I 1 RP  tunctional  arrjnments.  90  thoy  are  nl 

necessity  rpjife  slow.  lo  rjet  the  CAR  ot  a formula,  you  have  to  iiritn  f(  MAf  K 

(FUNCTION  CAR)  TMLAI;  this  binds  two  special  variables,  does  an  unrnmpil  itiln 

proper  ty- I I s t Inokup  nn  CAR,  and  still  returns  an  otiject  (siirh  as  " I f/l  ( I HM  IU( 
(P  ?KI  3)")  which  is  mean  I ng I P9S  without  further  liit-picking  in  Hie  fnimnla's 
enviroriment  tree. 

Alas,  these  prolilems  .are  complicated  an  order  ot  magnitude  hy  intor  art  inns 
uith  seunent  forms  arvl  emlierlrlerl  formulas.  (See  Appendix  1.)  Proressing  an 
emherlderl  formula  often  reciuires  setting  up  a stack  of  environments,  uh  1 r li  is 
(lushed  anr)  (iop(iert  as  ynu  c|n  into  a pair  of  brackets  or  encounter  an  nsr  ipp 
form. 


Cin.allg,  it  is  verij  )iai  d to  develop  intuitions  aliout  the  strurtuir>  nf 
environment  trees.  A hurjuy  program  that  manipulates  envids  doesn’t  do 
anything  radically  different  from  a correct  program;  it's  just  looking  at  Hie 
wrong  par 1 9 of  the  environment  tree.  The  envids  it  uses  are  just  I 1 t t I r> 
.integers  with  little  meaning.  Debugging  such  a program  usually  comes  down  to 
experimenting  with  different  numbers  until  something  works' 


Bibliography 


Abelson,  Robert  (1375)  "Concepts  for  Representing  Mundane  Reality  in  Plans." 
in  Bobrow  anr)  Collins  (1375). 

Alexander,  C.  (13RA)  Notes  on  the  Synthesis  of  form,  Cambridge:  Harvard 
University  Press. 

Asimow,  n.  (19R2)  Introduction  to  Design,  Englewood  Cliffs,  N.J. : Prentire- 
Ha II,  Inc. 

Bledsoe.  UI.U.  (1375)  Non-Resolution  Theorem  Proving,  The  University  of  Texas 
at  Austin,  Departments  o<  Mathematics  and  Computer  5ciences  Automatic 
Theorem  Proving  Project  Memo  ATP  29.  Based  on  a Tutorial  talk  giveia  .it 
IJCAI  4, 

Bledsoe,  W.U.  and  Mabry  Tyson  (1375)  The  UT  Interactive  Prover,  The  University 


0 I b I i OC|r  ) 


of  Texa*?  at  Austin,  Dnpartments  of  Mathematics  and  Comnuter  Sc i enr m 
Automatic  Theorem  Provinc)  Project  Memo  ATP  17. 

Botiron.  Daniel  G.  anti  Allan  M.  Collins  (1375)  (eds)  Representation  and 
Understand  ing.  Men  York:  Academic  Press. 

Bobrou,  Daniel  G.  and  Bertram  Raphael  (137A)  Neu  Programming  Lancjuagr.--.  ftn 
Artificial  Intelligence  Research,  Computing  Surveys  6,  No.  3,  p.  IGG. 

Bobroui,  Daniel  G.  and  Terrg  Uinograd  (137B)  An  Overview  of  KRl  , A Knowledge 
Representation  Language,  unpublished  paper,  version  of  May  28,  137G. 

Boyer,  R.S.  anri  J.S.  Monre  (1972)  "The  Sharing  of  Structure  in  Ttieorem  (’roving 
Programs, " in  Meltzer  and  Michie  (1372). 

Brand.  Myles  (137R)  The  Nature  oT  Human  Action,  Glenvieu,  I Minot''-;  Srntt, 
Foresman,  and  Com|iany. 

Bressan.  A I do  (13721  A General  Interpreted  Nodal  Calculus,  Neu  Haven:  Y.ile 

University  Press. 

Broun,  A.  (1975)  Qualitative  Knowledge,  Causal  Reasoning,  and  the  I oral \ /.it  ion 
of  Failures,  Cambridge:  unpublished  MIT  Ph.D.  thesis. 

Broun,  A.  and  G.J.  Sussman  (137A)  "Localization  of  Failure  in  Radm  Cnt'iits-- 
A Study  in  Causal  anrl  Teleological  Reasoning."  Cambridge;  MIT  A1  Lab  M»mn 
313. 

Buhl.  H.R.  (13G2)  Creative  Engineering  Design,  Ames,  loua:  The  Iona  Statr. 
University  Press. 

Buchanan,  Bruce,  Georgia  Sutherland,  and  E.A.  Feigenbaum  (1359)  "I  lEI  IH I '^>1 1 C. 
DENDRAL:  A Program  for  Generating  Explanatory  Hypotheses  in  Organic 

Chemistry,"  in  Meltzer  anil  Michie  (1953),  p.  203. 

Bundy,  Alan  (19751  "Analyzing  Mathematical  Proofs  (Or  Rearling  Refneen  the 
Lines),"  in  Proc.  IJCAl  ■), 

Charniak,  Eugene  (1372)  Toward  a Model  of  Children's  Story  Comprehension, 
Camtiridge,  Massactiuse  1 1 s:  MIT  A1  Lab  TR  265. 

Charniak,  Eugene  (1375)  "A  (partial  Taxonomy  of  Knouledge  about  Actions,"  Proc. 
IJCAl  4.  p.  91. 

Chohan,  V.C.  and  I.K.  Fuller  (197A)  "Computer  Aided  Design  of  Filters  loi  Data 
Transmission  Using  Freguency  Modulation,"  Proc.  Int.  ConF . on  CAP  V>.’4. 

Danto,  Arthur  C.  (1355)  "Basic  Actions,"  Am.  Phil.  Quart.  2,  p.  lAl.  Aim  in 
Brand  (1970) . p.  255. 

Oar  I i ng t on,  J,  L ( 19531  " Theorem  Proving  and  information  Re tr i eva I . " in  Me  I t zer 
and  Michie  (19531,  p.  173. 


Davisi.  naru).-)l  I (n7P)  Applications  of  Meta  Level  Knowledge  to  the 

Construction,  Maintenance,  and  Use  of  a Large  Knowledge  Bases,  Pi  inf'x'l  A| 
Lab  Memo  AIM-283. 

Davis,  Raorlall,  B.G.  Purhanan,  ant)  Edward  H.  Shortliffe  (137S)  Prodiictmn 
Rules  as  a Representation  for  a Knowledge-Based  Consultation  Progr.in, 
Stanford  University  AI  lalioratory  Memo  AIM-26G. 

Davis,  Ranrtall  and  Jonathan  I ng  (19/5)  An  Overview  of  Production  Systems, 
Stariford  University  A)  Laboratory  Memo  AlM-27). 

Director,  S.U.  (197A)  "Towarde  Automatic  Design  of  Integrated  Cirruits,"  m 
Spi I lers  (197A) , p.  3R3. 

Doyle,  Jon  (137GI  Analysis  by  Propagation  cf  Constraints  in  flementary 
Geometry  Problem  Solving.  Camtiridge:  MIT  AI  Lab  Dorking  Paper  ]R8. 

Doyle,  Jon  (13771  Tr.ith  Maintenance  Systems  for  Problem  Solving,  ramtir  cflf|e, 
Mass.;MlT  AI  Laboratory  Report  TR-A19. 

Eastman,  Charles  M.  (13G8)  Explorations  of  the  Cognitive  Processes  in  Design, 
unpublished  F’h.D.  dissertation,  Carneg i e-Me I I on  University. 

Eastman,  Charles  M.  (13G3)  "Problem-Solving  Strategies  in  Design."  Proc.  fnv. 
Des.  Res.  Ass.  Conf . 

Electronic  Design  (13GA)  400  Ideas  for  Design,  compiled  by  the  erlitors  of 
Electronic  Design  Mariajine.  New  York:  Hayden  Book  Company,  In'. 

El  I thorn,  Alick  anr)  David  Jones  (1373)  Artif  icial  and  Human  Thinking. 
Amsterdam:  Elsevier  Scientific  Publishing  Company. 

Ernst,  George  U.  (1371)  "The  Utility  of  Independent  Subgoals  in  Ttieoiem 
Proving,"  Information  and  Control,  April. 

Er.ist,  George  U.  (1373)  "A  Definition-Driven  Vheorem  Proven, " Proc.  IJtAI  ,), 
p.  51. 

Ernst.  George  U.  ami  Allen  Newell  (19G9)  CPS:  A Case  Study  in  Generality  and 
Problem-Solving,  New  York:  Academic  Press. 

Fahiman,  Scott  (1373)  A Planning  System  for  Robot  Construction  Tasks. 
Cambrifige:  MIT  AI  Lab  Technical  Report  283. 

Fahiman,  Scott  (13751  thesis  Progress  Report;  A System  for  Representing  and 
Using  Real-World  Knowledge,  Cambridge:  MIT  AI  Lab  Memo  ,331. 

Farber,  D.J.,  R.E.  Griswold,  and  I.P.  Polonsky  (19GA),  "SNDBOI  , A String 
Manipulation  Languaiie,"  JACM  II,  p.  21. 

Feigenbaum,  E.A.  and  J.  Feldman  (1963)  Computers  and  Thought,  New  York; 
McGraw-Hill  Book  Comiiany. 


n i b I i P'|r  .ipby 


?S8 


Fike9.  Rich.ircl  .ind  N i I J.  Nilgson  (1371)  "STRIPS:  A New  Apprn.i' b tn  Uip 

Application  ot  Ttmorpm  Proving  to  Problem  Solving,"  Proc . IJCA/  P,  p.  rH8. 

Fletchpr,  A.J.  (137A)  "EIIRCICA  --  A System  for  the  Automatic  Laynui  of  Single- 
Sided  Printed  Circuit  Boards, " Proc.  Int.  Conf  on  CAD  1974. 

Floyd,  Robert  (13S7)  "Assirining  Meanings  to  Programs,"  in  J.T,  Srt'iiar  tr  te'l.l. 
Mathematical  Aspects  of  Computer  Science,  p.  13. 

Freeman,  P,  and  Allen  Neiie  I I (1971)  "A  Model  for  Functional  Reasoninri  in 
Design,"  Proc.  IJCAl  p,  621. 

Furman,  T,A,  (13701  (ed. ) the  Use  of  Computers  in  engineering  Design,  I riririrm: 
English  Universities  Press. 

Clegg,  Gordon  Lindsay  (1973)  The  Science  of  Design,  Cambridge  Llniversitg 
Press. 

Goldman,  Alvin  1,  (1370)  A Theory  of  Human  Action,  Engleuocr)  Cliffs,  N.  I.: 

Prentice-Hall,  Inc. 

Grason,  John  (1370)  Method.s  for  the  Computer- Implemented  Solution  of  a Class 
of  "floor  Plan"  Design  Problems,  unpublished  Ph.D.  dissertation,  Carnetiip 
Mellon  University. 

Gray,  P,E.  and  C.L.  Sear  Ip  (1369)  Electronic  Principles:  Physics,  Models,  and 
Circuits,  Neu  York:  John  Uiley  S Sons,  Inc. 

Green,  C.  Cordell  (1363a)  The  Application  of  Theorem  Proving  to  Quest  ion- 
Answering  Systems,  Standford:  Stanford  University  Computer  Science 
Department  Report  CS-138, 

Green,  C.  Cordell  (1963b)  "Theorem-Proving  by  Resolution  as  a Basie  for 
Dues t i on-Ansuer  i ng  Systems,"  in  Meltzer  and  Michie  (1963). 

Haney,  Frederick  Marion  (13G8)  Using  a Computer  to  Design  Computer  Instruction 
Sets,  Pittsburgh:  Carneg  i e-Me  I I on  University  Computer  Science  Dep.ai  Iment 
Ph.D.  thesis. 

Hayes,  Patrick  J,  (1973a)  "The  Frame  Problem  and  Related  Problems  in 
Artificial  Intelligence,"  in  E I i thorn  and  Jones  (1973). 

Hayes,  Patrick  J.  (1973b)  "Computation  and  Deduction,"  Proc.  MFCS  Symp.  , 

Czech  Acad,  of  Sciences. 

Hayes,  Patrick  J.  (197A)  "Some  Problems  and  Non-Problems  in  Representation 
Theory,"  Sussex:  Proc.  AISB,  p.  63. 

Hayes,  Philip  (197S)  "A  Representation  for  Robot  Plans,"  IJCAl  4, 

Hayt,  Uilliam  H,  and  Gerold  U.  Neudeck  (1976)  Electronic  Circuit  Analysis  and 
Design,  Boston:  Houghton  Mifflin  Company, 


Heu I 1 1 , Carl  (1372)  Drscr  iption  and  Theoretical  Analysis  (Using  Schemata J of 
PIANNTR:  A Language  for  Proving  Theorems  and  Manipulating  Models  in  a 
Robot,  Cainljr  icige:  MIT  AI  Lab  TR-2S8. 

Hinti)^ka.  Ifairlo  Jaako  luhani  (19S2)  Knowledge  and  Belief:  an  Introduction  to 
the  Logic  of  the  Two  Notions,  Ithaca:  Cornell  University  Press. 

Hoare,  C.A.R.  (19£>3I  "An  AKiomatic  Basis  for  Computer  Programming,"  CACH  1?, 

p.  57G. 

Hughes,  G.E.  and  M.J.  Cressuell  (1972)  An  Introduction  to  Modal  logic,  I orulon 
Methuen  anr)  Co  I td. 

I^mg,  J.  (19691  A Program  Verifier,  Pittsburgh:  Carneq  i e-Me  M on  IJn  i vf’i  s I t ii 
Ph.D.  thesis. 

ICoualski,  Robert  (19731  Predicate  Logic  as  Programming  Language,  Efl i niim  gii: 
University  of  Edinljurgh  Department  of  Computat i ona I Logic  Memo  70. 

Koualski,  Robert  (197A)  Logic  for  Problem  Solving,  Edinburgh:  University  nf 
Edinqpurgh  Department  of  Computation  Logic  Memo  75. 

Koualski,  Robert  (13751  "A  Proof  Procedure  Using  Connection  Graphs."  J.  ACM 
?2,  p.  572. 

Kuo.  E.F.  anr)  UI.G.  Magnuson  (1969)  (eds. ) Computer -Or  lented  Circuit  Design, 

E nrj  I euond  C I I f f 3 , N.  I.  : Pr  en  t i ce-Ha  II,  Inc. 

L.angforil.  Glenn  (1371)  Human  Action,  Garden  City,  New  York:  Douhlerlay  K 
Company.  Inc. 

laiomiie.  lean  Claurle  (19  76)  Artificial  Intelligence  In  Computer-Aided  Design: 
1 he  "IROPIC"  System,  Menlo  Park:  Stanford  Research  Institute  Artificial 
Intelligence  Center  Technical  Note  125. 

Lehnert.  Uendy  (1375)  Question  Answering  In  a Story  Understanding  System,  Neu 
Haven:  Yale  University  |]omputer  Science  Research  Report  57. 

Marcus,  M,  (19731  WaU-anif!  Sec  Strategies  for  Parsing  Natural  Language, 
Cambridge:  M.  1 , T.  A.  I.  Lai)  Dorking  Paper  75, 

Marcus,  M.  (19751  "Diagnosis  as  a Notion  of  Grammar,"  Pre-prints  of  Uorkrlmp 
on  Theoretical  Issues  in  Natural  Language  Processing,  June  10-13.  137Ti. 

M.  I.T. 

Mason,  Matthew  (1376)  Qualitative  Simulation  of  Swine  Production,  Camhr  idrie: 
unpublistied  Ml  T bacheli^r's  thesis. 

Mattilat)  (197A)  MACSYSMA  Reference  Manual,  Cambridge:  Ml  T Artificial 

Intelligence  Laboratory. 

» 

) 

McCarthy,  John  (1353)  "Programs  with  Common  Sense,"  Proc.  Symposium  on 
Mechanization  of  Thought  Processes  I,  London:  Her  Majesty’s  Stationery 


B i b I i ogr  nphg 


260 


) 


Office.  Algo  in  HingKg  (1968),  p.  A03. 

flcCarthy,  John  and  Patrick  J.  Hayeg  (1969)  "Some  Philosophical  Prohinmg  (trim 
the  Standpoint  of  Artificial  Intelligence."  in  Meltzer  and  Mictiie  (19r,9), 
p.  A63. 


McDermott,  0.  (197Aa)  Assimilation  of  New  Information  by  a Natural  (angi/age- 
Understanding  System,  Cambridge:  fill  AI  Lab  TR  291. 


McDermott,  D. 
Camhr I dge: 


(197Ab)  Advice  on  the  Fast-Paced  World  of  Electronics, 
MIT  Al  Lab  Uorking  Paper  No.  71. 


McDermott,  D. 
Laboratory 


(1975)  Very  Large  Planner-Type  Data  Bases,  Cambridge: 
Memo  339. 


MIT  Al 


McDermott.  D. 
Cambr i dge: 


and  G.J.  Sussman  (1973)  The  Conniver  Keference  Manual, 
MIT  AI  Lab  Memo  2S9a. 


Meltzer,  Bernard,  and  Donald  Michie  (1969)  (eds. ) Machine  Intelligence  d.  Men 
York;  American  Elsevier  Publishing  Company,  Inc. 

Meltzer,  Bernard,  and  Donald  Michie  (1972)  (eds.)  Machine  Intelligence  7,  Neu 
Yor k-Toron t o:  John  Uiley  8 Sons. 

Michie,  Donald  (1968)  Machine  Intelligence  3,  Neu  York:  American  Elsevier 
Publishing  Company,  Inc. 

Minsky,  Marvin  (1968)  Semantic  Information  Processing,  Cambridge, 

Massachusse t 3 : MIT  Press. 


Minsky,  Marvin  (197A)  A Framework  for  Represent  ing  knowledge,  Camtu  idcjo:  MIT 

AI  Lab  Memo  30P.  Revised  version  in  Uinston  (197S). 

Moore,  J.  and  Allen  Neuell  (197A)  "Hou  Can  Merlin  Understand'^"  in  Cref|(|,  I , 
(ed.  I knowledge  and  Cognition,  Potomac.  Maryland:  Laurence  Erlhaum 
Assoc i a teg . 


Moore,  Robert  C.  (1975)  Reasoning  from  Incomplete  knowledge  in  a Procedural 
Deductive  System,  Camiir  i i-ige.  Mass.:  MIT  A|  Laboratory  TR  3A7. 

Nevins,  Arthur  (197Aa)  "A  Human  Oriented  Logic  for  Automatic  Thenr em-Pi  nv  i nc),  " 
JACM  PI,  no.  A.  p.  606. 

Nevins,  Arthur  (197Ab)  A Relaxation  Approach  to  Spffttfng  fn  an  Automatic 
Theorem  Prover,  Cambridge,  Massachusetts:  MIT  Al  Lab  Memo  302.  A I sn 
Artificial  Intelligence  6,  p.  25. 

Nevins,  Arttiur  (197Ac)  Plane  Geometry  Theorem  Proving  Using  Forward  Chaining, 
Cambr  idge:  MIT  AI  Lali  Memo  303, 

Neue I I , Allen  (1962)  "Some  Problems  of  Basic  Organization  in  Prob I em-5o I v i ng 
Progr.ams,"  in  Yovitts,  M.  , G.T.  Jacobi,  and  G.D.  Goldstein  (eds.)  Self- 
Organi/lng  Systems-- I96P,  f<eu  York:  Spartan. 


B 1 1> I I o'|f  tilt'  I 


.1.1 


Neuell,  Allpn  (19733)  "Protluc  (ion  Systems:  Horte  Is  ot  Control  S*rnr*ut<  in 
Chase,  U.C.  (eel.)  Visual  Information  Processing  (New  York:  Ar..ni<.mi( 
p.  AB3. 

Neuell,  Allpn  (1973b)  "Artificial  Intelligence  and  t he  Cone ep t of  (1 1 r ni , in 

Schank  and  CoMiy  (1973)  . p.  1. 

Nilsson,  Nils  J,  (1971)  Problem-Solving  Methods  in  Artificial  Intel  1 igmer , 

New  York:  (IcGrau-Hill  Book  Company. 

Nilsson,  Nils  J.  (1373)  A Hierarchical  Robot  Planning  and  Execution  System. 
npnio  Park,  California:  oRI  Artificial  Intelligence  Center  Technic-il  Note 
7G. 

Pople,  H.E.,  Jr.  (1973)  "On  the  Hechanizat ion  of  Abductive  Logic,"  Proc. 

IJCAI  3. 

Powers,  Gary  J.  (13721  "Computer  Aided  Synthesis  of  Chemical  Processing 

Systems,"  Proc.  6th  Princeton  Conf.  on  Information  Sci.  and  Systems,  p.  A2. 

Powers,  Gary  J.  (1973)  "Non-Numer i ca I Problem  Solving  Methods  in  Compulnt 
Aided  Design,"  in  Vlietstra  and  Uielinga  (1973). 

Powers,  Gary  J.  and  Dale  F.  Rudd  (197A)  "A  Theory  for  Chemical  Enginpei  inci 
Design,"  in  SpiMers  (197A). 

Prior.  Arthur  N,  (1957)  Time  and  Modality,  Oxford:  Clarendon  Press. 

Prior.  Arthur  N.  (1967)  Past,  Present,  and  Future,  Oxford:  Clarendon  Prr.r,.-,, 

Rescher,  Nicholas  and  Alasdair  Urquhart  (1971)  Temporal  Logic,  New  Ymk: 

Spr i nger -Ver I ag. 

I Rieger,  Charles  (1976)  "An  Organization  of  Knowledge  for  Problem  Solvin')  anil 

Language  Compr  eliens  i on. " Artificial  Intelligence  7,  No.  2.  p.  89. 

I 

Robinson,  J.A.  (1965)  "A  Mach  I ne-or  i ented  Logic  Based  on  the  Resolution 
I Principle."  JACM  12. 

Rosenbrock,  H,H.  (197A)  Computer-Aided  Control  System  Design,  London: 

I Academic  Press. 

I 

[ Rulifson,  J.F.,  J.A.  Derksen,  and  R.J.  Ualdinger  (1972)  QA4 : A Procedur,^! 

, Calculus  for  Intuitive  Reasoning,  Menlo  Park:  SRI  Technical  Note  73. 

Rychener,  Michael  D.  (1975)  The  Studnt  Production  System:  A Study  of  [ncoding 
I Knowledge  in  Production  Systems,  Pittsburgh:  Carnegie-Mel  Ion  llnivei'iity 

' Department  of  Computer  Science. 

Rychener,  Michael  0.  (1976)  Production  Systems  as  a Programming  language  for 
Artificial  Intelligence  Applications,  Pittsburgh:  Carneg i e-Me I I on 
University  Department  of  Computer  Science,  in  preparation. 


■d 


Sacerdoli,  Earl  D.  (1975)  A Structure  for  Plans  and  Behavior,  SRI  Artificial 
Intelligence  Center  Technical  Note  109. 

Schank,  Roger  (1975)  "The  Structure  of  Episodes  in  flemory,"  in  Bohrou  anrl 
Col  I ins  (1975),  p.  237. 

Schank,  Roger  and  Robert  Abelson  (1975)  "Scripts,  Plans,  and  ICnoul  erl(|r>,  " Prnc . 
IJCAI  4. 

Schank,  Roger  and  (Kenneth  Mark  Colby  (1973)  Computer  Models  of  Thought  and 
Language , San  Francisco:  U.H.  Freeman  and  Company. 

Senturia,  Stephen  D.  and  Bruce  D.  Uedlock  (1975)  Electronic  Circuits  and 
Applications,  Neu  York:  John  Wiley  and  Sons.  Inc. 

Shortliffe,  Eduard  M.  (1975)  Computer-Based  Medical  Consultations:  MYCIN,  Neu 
York:  American  Elsevier  Publishing  Company,  Inc. 

Siklossy,  L.  and  J.  Roach  (1973)  "Proving  the  Impossible  is  Impossilile  is 
Possible:  Disproofs  Based  on  Hereditary  Partitions,"  in  Proc . IJCAI  T,  p. 
383. 

Slagle,  James  R.  (1971)  Artificial  Intelligence;  The  Heuristic  Prograimning 
Approach,  Neu  York;  flcGrau-HI  1 1 Book  Company, 

Spillers,  William  R.  (197A)  (ed.)  Sasfc  Questions  of  Design  Theory,  Neu  York: 
American  Elsevier  Pul)lishlng  Company,  Inc. 

Srinivasan,  Chitoor  V.  (197Ra)  Introduction  to  the  Meta  Description  System. 

Neu  Brunsuick,  N.J.:  Rutgers  University  Dept,  of  Computer  Science  SDSAP-TR- 
18. 

Srinivasan,  Chitoor  V,  (197Gb)  "The  Architecture  of  Coherent  Information 

System:  A General  Problem  Solving  System,"  IEEE  Trans,  on  Computers  C-^5, 

no.  A,  p 390. 

Stallman,  Richard  M.  and  Gerald  J.  Sussman  (1976)  forward  Reasoning  and 
Dependency-Directed  Backtracking  In  a System  for  Computer-Aided  Circuit 
Analysis,  Cambridge:  MIT  AI  Lab  Nemo  380. 

Stickel,  (lark  E.  (1975)  "A  Complete  Unification  Algorithm  for  Assoc i at  ive- 
Commutative  Functions,"  Proc.  IJCAI  4, 

Suppes,  Patrick  (1957)  Introduction  to  Logic,  New  York:  Van  Nostrand  Rpinliolcl 
Company. 

Sussman,  Gerald  J.  (1975)  A Computer  Model  of  Skill  Acquisition,  Neu  York: 
American  Elsevier  Publishing  Company. 

Sussman,  Gerald  J,  and  D.V.  McDermott  (1972)  "From  PLANNER  to  CONNIVED  --  A 
Genetic  Approach,"  Proc.  FJCC  41,  p.  1171. 

Sussman,  Gerald  J.  and  Richard  M,  Stallman  (1975)  "Heuristic  Tectmigups  in 


1 


B i b I i OC)r  .iphi  ) 


rr.  < 


Compu t er - A i cled  Circuit  Analysis,"  Ifff  Trans,  on  Circuits  and  Systrms  ??, 
p.  8S7. 

Tarnlund,  Sten-Ake  (1975)  "An  Interpreter  for  the  Programming  Lanc)uagn 
Predicate  Logic,"  Proc.  IJCAI  4,  p.  G01. 

Tate,  Austin  (1975)  "Interacting  Goals  and  Their  Use,"  Proc.  IJCAI  4. 

Travis,  Larry,  Charles  K'eltogg,  and  Philip  kJIahr  (1972)  Inferential  Ourslinn- 
Answering:  Extending  CONVERSE,  mimeo. 

Tulving,  Endel  and  Ulayne  Donaldson  (1972)  Organization  of  Memory,  Neu  Yoik: 
Academic  Press. 

Vlietstra.  J.  and  R.F.  Uielinga  (1973)  (eds.)  Computer-Aided  Design, 
Amsterdam:  Nor th- Ho  I I and  Publishing  Company,  Inc. 

Ualdinger,  Richard  J.  and  K.N.  Levitt  (197A)  "Reasoning  about  Programs," 
Artificial  Intelligence. 

Uarren,  David  H.D.  (1974)  WARPLAN;  A System  for  Generating  Plans,  E<l  i niv  n- r|h: 
University  of  Edinburgh  Department  of  Computational  Logic  Memo.  No.  75. 

Uatson,  J.  (197R)  Semiconductor  Circuit  Design;  for  a.f.  and  d.c. 
Amplification  and  Switching,  London:  Adam  Hilger  Ltd. 

Uinston,  Patrick  H.  (1975)  The  Psychology  of  Computer  Vision,  NcGrau-Hill. 


I 

i 

\ 

1 


I 


